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PREFACE 


The purpose of this guide is to enable 
programmers to compile, link edit, and 
execute FORTRAN IV programs under control 
of IBM System/360 Operating System, The 
FORTRAN IV language is described in the 
publication IIM System/360 FORTRAN IV Lan¬ 
guage , Form C28-6515, which is the corequi¬ 
site to this publication. 


The Programmer's Guide is organized to 
fulfill its purpose at three levels: 

1. Programmers who will use the cataloged 
procedures as provided by IBM should 
read the "Introduction" and "Job Con¬ 
trol Language" sections to understand 
the job control statements, the 
"FORTRAN Job Processing" section to 
understand the use of cataloged proce¬ 
dures, the "Programming Considera¬ 
tions" section to be able to use the 
FORTRAN language correctly and effi¬ 
ciently, and the "System Output" sec¬ 
tion to understand the listings, maps, 
and messages generated by the compil¬ 
er, the linkage editor, and a load 
module. 

2. Programmers who, in addition, are con¬ 
cerned with creating and retrieving 
data sets, optimizing the use of I/O 
devices, or temporarily modifying IBM- 
supplied cataloged procedures should 
read the entire Programmer's Guide. 

3. Programmers concerned with making 
extensive use of the operating system 
facilities, such as writing their own 
cataloged procedures and modifying the 
FORTRAN library, should also read the 
entire Programmer's Guide in conjunc¬ 
tion with the following publications, 
as required: 

IBM System/360 Operating System: Job 
Control Language , Form C28-6539 

IBM System/360 Operating System: Sys¬ 
tem Programmer's Guide , Form C28-6550 

IBM System/360 Operating System: Data 
Management , Form C28-6537 


IBM System/360 Operating System: Util¬ 
ities , Form C28-6586 


IBM System/360 Operating System: 
FORTRAN IV, Library Subprograms , Form 
C28-6596 

IBM System/360 Operating System: Link¬ 
age Editor , Form C28-6538 

IBM Systeirt/360 Operating System: Sys¬ 
tem Generation , Form C28-6554 

IBM System/360 Operating System: 

Operator's Guide , Form C28-6540 

IBM System/360 Operating System: Con¬ 
trol Program Messages, Completion 
Codes, and Storage Dumps , Form 
C28-6631 

This publication contains appendixes 
that provide the programmer with the fol¬ 
lowing information: 

• Descriptions and explanations of com¬ 
piler invocation from a problem pro¬ 
gram. 

• Examples of job processing. 

• Descriptions and explanations for the 
preparation of subprograms written in 
assembler language for use with a main 
program written in FORTRAN. 

• Detailed descriptions of the diagnostic 
messages produced during compilation 
and load module execution. 

• A list of ASA carriage control charac¬ 
ters . 

• Descriptions of the output from the 
debug facility. 

For easier reading, the titles of publi¬ 
cations referred to in this publication are 
abbreviated. For example, references to 
the publication IBM System/360 Operating 
System: Linkage Editor are abbreviated to 

" Linkage Editor publication." 
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INTRODUCTION 


The IBM System/360 Operating System (the 
operating system) consists of a control 
program and processing programs. The con¬ 
trol program supervises execution of all 
processing programs, such as the FORTRAN 
compiler, and all problem programs, such as 
a FORTRAN program. Therefore, to execute a 
FORTRAN program, the programmer must first 
communicate with the operating system. The 
medium of communication between the pro¬ 
grammer and the operating system is the job 
control language. 

The programmer uses job control state¬ 
ments to define two units of work to the 
operating system: the job and the job step, 
and to define the files (data sets) used in 
these jobs and job steps. He defines a job 
to the operating system by using a JOB 
statement; a job step by using an EXEC 
statement; and a data set by using a DD 
statement. 


JOB AND JOB STEP RELATIONSHIP 

To the operating system, a job consists 
of executing one or more job steps. In the 
simplest case, a job consists of one job 
step. For example, executing a FORTRAN 
main program to invert a matrix is a job 
consisting of one job step. 

In more complex cases, one job may 
consist of a series of job steps. For 
example, a programmer is given a tape 
containing raw data from a rocket firing: 
he must transform this raw data into a 
series of graphs and reports. Three steps 
may be defined: 

1. Compare the raw data to projected data 
and eliminate errors which arise 
because of intermittent errors in 
gauges and transmission facilities. 

2. Use the refined data and a set of 
parameters as input to a set of equa¬ 
tions, which develop values for the 
production of graphs and reports. 

3. Use the values to plot the graphs and 
print the reports. 

Figure 1 illustrates the rocket firing 
job with three job steps. 

In the previous example, each step could 
be defined as a separate job with one job 
step in each job. However, designating 
related job steps as one job is more 
efficient: processing time is decreased 


because only one job is defined, and inter¬ 
dependence of job steps may be stated. 
(The interdependence of joos cannot Joe 
stated.) 



Figure 1. Rocket Firing Job 


FORTRAN PROCESSING AND CATALOGED PROCEDURES 

When a programmer writes a FORTRAN pro¬ 
gram, the objective is to obtain a problem 
solution. However, before the program can 
provide this solution, the program itself 
must undergo processing. The source pro¬ 
gram (source module) is compiled to give an 
object module; and the object module is 
link edited to give a load module. This 
load module is then executed to give the 
desired problem solution. 

If each of the three steps involved in 
processing a FORTRAN module is a job step 
in the same job, a set of job control 
statements that consists of one EXEC state¬ 
ment and one or more DD statements is 
required for each step. Because writing 
these job control statements can be time- 
consuming work for the programmer, IBM 
supplies cataloged procedures to aid in the 
processing of FORTRAN modules. A cataloged 
procedure consists of a procedure step or a 
series of procedure steps. Each step 
contains the necessary set of job control 
statements to compile or to link edit or to 
execute a FORTRAN module. ( Note : A JOB 
statement cannot be cataloged.) 


I nt r odu ct i on 
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Four FORTRAN cataloged procedures are 
supplied by IBM, These four cataloged 
procedures and their uses are: 


FORTGC 

FORTGCL 

FORTGLG 

FORTGCLG 


compile 

compile and link edit 
link edit and execute 
compile, link edit, and execute 


Any of the cataloged procedures can be 
invoked by an EXEC statement in the input 
stream. In addition, each of the proce¬ 
dures can be temporarily modified by this 
EXEC statement and any DD statements in the 
input stream; this temporary modification 
is called overriding. 


lar, they are used for storage of source 
and load modules (each module is a member). 
In fact, a load module can be executed only 
if it is a member of a partitioned data 
set. A PDS of load modules is created by 
either the linkage editor or a utility 
program. A PDS is accessible to the link¬ 
age editor; however, only individual mem¬ 
bers of a PDS are accessible to the compil¬ 
er. Members of a PDS are not accessible to 
a FORTRAN load module. 


The FORTRAN library is a cataloged PDS 
that contains the library subprograms in 
the form of load modules. SYS1.FORTLIB is 
the name given to this PDS. 


DATA SETS 

For FORTRAN processing, a programmer 
uses DD statements to define the particular 
data set(s) required for a compile, link 
edit, or execute step. In the operating 
system, a data set is a named, organized 
collection of one or more records that are 
logically related. For example, a data set 
may be a source module, a library of 
mathematical functions, or the data proc¬ 
essed by a load module. 


Data Set Organization 

A data set is a named collection of 
data. Several methods are available for 
internally organizing data sets. Three 
types of data sets are accessible in 
FORTRAN processing: sequential data sets, 
partitioned data sets, and direct access 
data sets. 


A direct access data set contains 
records that are read or written by speci¬ 
fying the position of the record within the 
data set. When the position of the record 
is indicated in a FIND, READ, or WRITE 
statement, the operating system goes 
directly to that position in the data set 
and either retrieves, reads, or writes the 
record. For example, with a sequential 
data set, if the 100th record is read or 
written, all records preceding the 100th 
record (records 1 through 99) must be 
transmitted before the 100th record can be 
transmitted. With a direct access data set 
the 100th record can be transmitted direct¬ 
ly by indicating in the I/O statement that 
the 100th record is to be transmitted. 
However, in a direct access data set, 
records can only be transmitted by direct 
access I/O statements; they cannot be 
transmitted by sequential I/O statements. 
Records in a direct access data set can be 
transmitted sequentially by using the asso¬ 
ciated variable in direct access I/O state¬ 
ments . 


A sequential data set is organized in 
the same way as a data set that resides on 
a tape volume, but a sequential data set 
may reside on any type of volume. The 
compiler, linkage editor, and load modules 
process sequential data sets. The compiler 
uses the queued sequential access method 
(QSAM) for such processing, and load 
modules use the basic sequential access 
time method (BSAM) for object time I/O 
operations. 


A partitioned data set (PDS) is composed 
of named, independent groups of sequential 
data and resides on a direct access volume. 
A directory index resides in the PDS and 
directs the operating system to any group 
of sequential data. Each group of sequen¬ 
tial data is called a member . (A member of 
a PDS is not a data set.) Partitioned data 
sets are used for storage of any type of 
sequentially organized data. In particu¬ 


A direct access aata set must resiae on 
a direct access volume. Direct access data 
sets are processed by FORTRAN load modules; 
the compiler and linkage editor cannot 
process direct access data sets. Load 
modules process data sets of this type witn 
the basic direct access method (BDAM). 

Saying that a data set is sequential, 
partitioned, or direct access reflects its 
organization. Saying that a data set is 
cataloged or that it is a generation data 
set reflects a method of retrieving tne 
data set. Sequential, partitioned, ana 
direct access data sets can ae cataloged; 
however, an individual member of a PDS 
cannot be cataloged because a member is not 
a data set. A generation data set can onl^ 
be a sequential or direct access data set; 
a generation data set cannot be a PDS or a 
member of a PDS. (See the section "Job 
Control Language" for information on how to 
specify a generation data set.) 
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Data Set Labels 

Data sets that reside on direct-access 
volumes have standard labels only; data 
sets that reside on magnetic tape volumes 
can have standard labels or no labels. 
Information, such as a data set identifier, 
volume sequence number, record format, den¬ 
sity, etc., is stored in the data set 
labels. The information required in the DD 
statement used to retrieve a labeled data 
set is substantially less than that 
required to retrieve an unlabeled data set. 


Data Set Cataloging 

To relieve the programmer of the burden 
of remembering the volume on which a par¬ 
ticular data set resides, the operating 
system provides a cataloging facility. 
When a data set is cataloged, the serial 
number of its volume is associated in the 
catalog with the data set name. A program¬ 
mer can refer to this data set without 
specifying its physical location. Any data 
set residing on a direct-access or magnetic 
tape volume can be cataloged. 
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JOE CONTROL LANGUAGE 


The FORTRAN programmer uses the job 
control statements shown in Table 1 to 
compile, link edit, and execute programs. 


Table 1. 


Job Control Statements 


j Statement j 

h 


Function 


JOB 


Indicates the beginning of a 
new job and describes that job. 


H 


EXEC 


Indicates a job step and de¬ 
scribes that job step; indi¬ 
cates the cataloged procedure 
or load module to be executed. 


H 


DD 


h 


Describes data sets, and con¬ 
trols device and volume assign¬ 
ment. 


H 


delimiter 


Separates data sets in the 
input stream from control 
statements; it appears after 
each data set in the input 
stream. 


CODING JOB CONTROL STATEMENTS 


Job control statements are identified by 
the initial characters // or /* in card 
columns 1 and 2, and may contain three 
fields — name, operation, and operand (see 
Figure 2). 


NAME FIELD 

The name contains between one and eight 
alphameric characters, the first of which 
must be alphabetic. The name begins in 
card column 3 and is followed by one or 
more blanks to separate it from the opera¬ 
tion field. The name is used in the 
following ways: 

1. To identify the control statement to 
the operating system. 

2. To enable other control statements in 
the job to refer to information con¬ 
tained in the named statement. 


3. To relate DD statements to 1/0 state¬ 
ments in the load module. 


OPERATION FIELD 

The operation field contains one of the 
following operation codes: 

JOB 

EXEC 

DD 

If the statement is a delimiter state¬ 
ment, the operation field is blank. The 
operation code is preceded and followed by 
one or more blanks. 


OPERAND FIELD 

The operand field contains the parame¬ 
ters that provide required and optional 
information to the operating system. 
Parameters are separated by commas, and the 
operand field is ended by placing one or 
more blanks after the last parameter. 
There are two types of parameters; posi¬ 
tional and keyword. 

Positional Parameters: Positional parame¬ 
ters are placed first in the operand field 
and must appear in the specified order. If 
a positional parameter is emitted and other 
positional parameters follow, the omission 
must be indicated by a comma. 

Keyword Parameters: Keyword parameters 
follow positional parameters in the operand 
field. (If no positional parameters 
appear, a keyword parameter can appear 
first in the operand field; no leading 
comma is required.) Keyword parameters are 
not order dependent, i.e., they may appear 
in any order. If a keyword parameter is 
omitted, a comma is not required to indi¬ 
cate the omission. 

Subparameters: Subparameters are either 
positional or keyword and are noted as suen 
in the definition of control statements. 


r- t- ~\ 

| FORMAT | APPLICABLE CONTROL STATEMENTS j 

h-+--I 

|//Name Operation Operand [Comment] |JOB,EXEC,DD | 

|// Operation Operand [Comment] |EXEC,DD | 

j/* [Comment] jdelimiter | 

L_J._J 

Figure 2. Job Control Statement Formats 
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Positional subparameters appear first in 
a parameter and must appear in the speci¬ 
fied order. If a positional subparameter 
is omitted and other positional subparame¬ 
ters follow, the omission must be indicated 
by a comma. 

Keyword subparameters follow positional 
subparameters in a parameter. (If no posi¬ 
tional subparameters appear, a keyword sub¬ 
parameter can appear first in the parame¬ 
ter; no leading comma is required.) Key¬ 
word subparameters are not order dependent, 

i.e., they may appear in any order. If a 
keyword subparameter is omitted, a comma is 
not required to indicate the omission. 


CONTINUING CONTROL STATEMENTS 

A control statement can be written in 
card columns 1 through 72. If a control 
statement exceeds 71 columns, it may be 
continued onto the next card. The continu¬ 
ation must be interrupted after the comma 
that follows the last parameter on the card 
and a nonblank character must be placed in 
column 72. The continuation card must 
contain // in columns 1 and 2, blanks in 
columns 3 through 15, and the continued 
portion of the statement must begin in 
column 16. 

Note: Excessive continuation cards should 
be avoided whenever possible to reduce 
processing time for the control program. 


COMMENTS 

Comments must be separated from the last 
parameter (or the * in a delimiter 
statement) by one or more blanks and may 
appear in the remaining columns up to and 
including column 71. 

However, comments may be continued by 
placing a nonblank character in column 72, 
// in columns 1 and 2 of the continuation 
card, and continuing the comment in any 
column after column 15 (columns 3-15 must 
be blank). There is no limit to the number 
of continuation cards that may be used for 
a single control statement or comment. 
Also, there is no limitation placed upon 
the number of comment cards that may be 
contained in the source program. 


NOTATION FOR DEFINING CONTROL STATEMENTS 

The notation used in this publication to 
define control statements is described in 
the following paragraphs. 

1. The set of symbols listed below are 
used to define control statements, but 


are never written in an actual state¬ 
ment . 


a. 

hyphen 

- 

b. 

or 

1 

c. 

underscore 


d. 

braces 

{“} 

e. 

brackets 

[ ] 

f. 

ellipsis 

. . . 

g- 

superscript 

± 


The special uses of these symools are 
explained in paragraphs 4-10. 


2. Uppercase letters and words, numbers, 
and the set of symbols listed below 
are written in an actual control 
statement exactly as shown in the 
statement definition. (Any exceptions 
to this rule are noted in the defini¬ 
tion of a control statement.) 

a. apostrophe ' 

b. asterisk * 

c. comma , 

d. equal sign = 

e. parentheses ( ) 

f. period 

g. slash / 

3. Lowercase letters, woras, ana symbols 
appearing in a control statement defi¬ 
nition represent variables for which 
specific information is substitutea in 
the actual statement. 

Example : If "name" appears in a state¬ 
ment definition, a specific value 
(e.g., ALPHA) is suostituted for the 
variable in the actual statement. 

4. Hyphens join lowercase letters, words, 
and symbols to form a single variable. 

Example : If "member-name" appears in a 
statement definition, a specific value 
(e.g., BETA) is substituted for the 
variable in the actual statement. 

5. Stacked items or items separated from 
each other by the "or" symbol rep¬ 
resent alternatives. Only one such 
alternative should be selected. 

Example : The two representations 
A 

B and A|B|C 
C 

have the same meaning ana indicate 
that either A or B or C should be 
selected. 

6. An underscore indicates a default 
option. If an underscored alternative 
is selected, it need not be written in 
the actual statement. 
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Example ; The two representations 
A 

B and A|B|C 
C 


have the same meaning and indicate 
that either A or B or C should be 
selected; howel/er, if B is selected, 
it need not be written, because it is 
the default option. 

7. Braces group related items, such as 
alternatives. 


Example : 

ALPHA=({A|B|C},D) 

Indicates that a choice should be made 
among the items enclosed within the 
braces. If A is selected, the result 
is ALPHA=(A,D). If C is selected, the 
result can be either ALPHA=(,D) or 
ALPHA=(C,D). 

8. Brackets also group related items; 
however, everything within the brack¬ 
ets is optional and may be omitted. 

Example : 

ALPHA=([A|B|C],D) 

indicates that a choice can be made 
among the items enclosed within the 
brackets or that the items within the 
brackets can be omitted. If B is 
selected, the result is ALPHA=(B,D). 
If no choice is made, the result is 
ALPHA=(,D). 

9. An ellipsis indicates that the preced¬ 
ing item or group of items can be 
repeated more than once in succession. 


Example : 

ALPHA[,BETA]... 


indicates that ALPHA can appear alone 
or can be followed by ,BETA repeated 
optionally any number of times in 
succession. 

10. A superscript refers to a prose de¬ 
scription in a footnote. 


Example : 


NEW] 3 - 
OLD > 
MODJ 


indicates that additional information 
concerning the grouped items is con¬ 
tained in footnote number 1. 


11. Blanks are used to improve the reada¬ 
bility of control statement defini¬ 
tions. Unless otherwise noted, blanks 
have no meaning in a statement defini¬ 
tion. 


« 


JOB STATEMENT 

The JOB statement (Figure 3) is the 
first statement in the sequence of control 
statements that describe a job. The JOB 
statement contains the following informa¬ 
tion: 

1. Job name. 

2. Accounting information relative to the 
job. 

3. Programmer's name. 

4. Whether the job control statements are 
printed for the programmer. 

5. Conditions for terminating the execu¬ 
tion of the job. 

Examples of the JOB statement are showm 
in Figure 4. 




NAME FIELD 

The "jobname" must always be specified; 
it identifies the job to the operating 
system. 


OPERAND FIELD 

Account Number and Accounting Information 

The first positional parameter can con¬ 
tain the installation account number and 
any parameters passed to the installation 
accounting routines. These routines are 
written by the installation and inserted in 
the operating system when it is generated. 
The format of the accounting information is 
specified by the installation. 

Programmer's Name 

The "programmer name" is the second 
positional parameter. 

Control Statement Messages 

The MSGLEVEL parameter indicates the 
type of control statement messages the 
programmer wishes to receive from the con¬ 
trol program.. 

MSGLEVEL=0 

indicates that only control statement 
errors and diagnostic messages are 
written for the programmer. 

MSGLEVEL=1 

indicates that all control statements 
as well as control statement errors 
and diagnostic messages are written 
for the programmer. 



* 
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~T -T- 

|Operation!Operand 


| Name 


h 


//jobname 


h 


JOB 


Positional Parameters 

[([account-number][,accounting-information]) 1 2 3 ] 
[, programmer-name] ** 5 6 

Keyword Parameters 

f MSGLEVEL=Q \ 

\msglevel=i ) 

[COND= C(code,operator) [, (code,operator)]. . . 7 ) 8 ] 


H 


^-If the information specified ("account-number” and/or "accounting-information") con¬ 
tains blanks, parentheses, or equal signs, it must be delin.ited by apostrophes instead 
of parentheses. 

2 If only "account-number" is specified, the delimiting parentheses may be omitted. 

3 The maximum number of characters allowed between the delimiting parentheses or 
apostrophes is 144. 

4 If "programmer-name" contains commas, parentheses, apostrophes, or blanks, it must be 
enclosed within apostrophes. 

5 When an apostrophe is contained within "programmer-name", the apostrophe must be shown 
as two consecutive apostrophes. 

6 The maximum number of characters allowed for "programmer-name" is 20. 

7 The maximum number of repetitions allowed is 7. 

8 If only one test is specified, the outer pair of parentheses may ue omitted. 

L_ 

Figure 3. JOB Statement 

Example 1: 


Sample Coding Form 


I -10 


11-20 _ 21-30 _ 31-40 _ 41-50 51-60 61-70 71-80 

I |2|3|4|5i6|7|8|9|0ll |2|3|4|5l6|7|8|9|Q|l |2|3|4|5|6 l7|8|9 |QiTf2|3|4|5|6|7l8|9|0ll |2f3T4l5|6|7|8|9|0|l |2|3|4|5|6|7|8|9|0|l |2|3|4|5|6|7|8|9ld 


I2I3I4I5I6I7I8T9T0 


\BiX\ampJie\ h 


_1_I_I_L_ 


/,/,P,R,0iG,R,A,M |J,0,B, ,(i2,l i 5,) l 8 | l,9 l r4,6 l l«0,^ l \J | vSMI,T|H, / ,?,C0,M l D, s ,(,7|?,L,T,),?|MS,GL i E|VE i L =1 | 


J_i_I_ i I i _l_l_L 

J_I_i_1_I_l_l_ i | i _i_l_l_l_J_I_I_L 

j_i_i_L 


£-AQmpJe\ Z 


J_I_1 I 1 I I_L L.J_I_I_1_I_I_ 




Lissm ,J,0|B.^.8 l 7.F.-^i>,C,0.W.D ! -,C7,rL l T.). 


1 L.. 




I J I 


Figure 4. Sample JOB Statements 


Conditions for Terminating a Job 

At the completion of a job step, a code 
is issued indicating the outcome of the job 
step. The generated code is tested against 
the conditions stated in control state¬ 
ments . The error codes generated by the 
FORTRAN compiler are: 

0 - No errors or warnings detected. 

4 - Possible errors (warnings) detected, 
execution should be successful. 

8 - Errors detected, execution may fail. 
Compilation continues regardless of 
the errors. If a LOAD option has been 
specified, a LOAD module will be sup¬ 
plied unless the error code generated 
is greater than the error level speci¬ 
fied by the programmer. 


12 - Severe errors detectea, execution is 
impossible. 


16 - Terminal errors detected, compiler 
operation terminated. (If a terminal 
error is detected during load module 
execution, a 16 is issued.) 

The COND parameter specifies conditions 
under which a job is terminated. Up to 
eight different tests, each consisting of a 
code and an operator, may be specifita to 
the right of the equal sign. The code maj 
be any number between 0 ana 4095. The 
operator indicates the mathematical rela¬ 
tionship between the code placed in the JOB 
statement and the codes issued by completed 
job steps. If the relationship is true , 
the job is terminated. The six operators 
and their meanings are: 
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Operator 

Meaning 



GT 

greater than 



GE 

greater than 

or equal 

to 

EQ 

equal to 



NE 

not equal to 



LT 

less than 



LE 

less than or 

equal to 


For example. 

if a code 8 is 

returned 

by 


the compiler and the JOB statement con¬ 
tains : 

COND=<7,LT) 

the job is terminated. 

If more than one condition is indicated 
in the COND parameter and any condition is 
satisfied, the job is terminated. 


EXEC STATEMENT 

The EXEC statement (Figure 5) indicates 
the beginning of a job step and describes 


that job step. The statement can contain 
the following information: 


1. Name of the job or procedure step. 


2. Name of the cataloged procedure or 
load module to be executed. 


3. Compiler and/or linkage editor options 
passed to the job step. 


4. Accounting information relative to 
this job step. 

5. Conditions for bypassing the execution 
of this job step. 

Example 1 of Figure 6 shows the EXEC 
statement used to execute a program. Exam¬ 
ple 2 in Figure 6 shows an EXEC statement 
that invokes a cataloged procedure. 


r- 

| Name 


“T-T- 

|Operation! Operand 


//[stepname ] ± 




EXEC 


Positional Parameter 

{ PROC=cataloged-procedure-name ^ 
cataloged-procedure-name 
PGM=program-name 
PGM=*.stepname.ddname 
PGM=*.stepname.procstep.ddname 

Keyword Parameters 

JpaRM 1 

|PARM.procstep 2 J= (option[,option] ...) 3 u 5 

Jacct 

IACCT.procstep 2 = (accounting-inforrnation) 3 6 7 
|COND | 

|COND.procstep 2 ] =((code,operator[,stepname[.procstep] ]) 
[,(code,operator[,stepname[.procstep]])]... 8 ) 9 ] 


H 


is referreu to 


later job step. 


*-If information from this control statement 
"stepname" is required. 

2 If this format is selected, it may be repeated in the EXEC statement, once for each 
step in the cataloged procedure. 

3 If the information specified contains blanks, parentheses, or equal signs, it must be 
delimited by apostrophes instead of parentheses. 

4 If only one option is specified and it does not contain any blanks, parentheses, or 
equal signs, the delimiting parentheses may be omitted. 

5 The maximum number of characters allowed between the delimiting apostrophes or 

parentheses is 40. The PARM parameter cannot occupy more than one card. 

6 If "accounting-inforrnation" does not contain commas, blanks, parentheses, or equal 
signs, the delimiting parentheses may be omitted. 

7 The maximum number of characters allowed between the delimiting apostrophes or 

parentheses is 144. 

8 The maximum number of repetitions allowed is 7. 

9 If only one test is specified, the outer pair of parentheses may be omitted. 


Figure 5. EXEC Statement 
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Sample Coding Form 


I-10 


11-20 


21-30 


31-40 


| ]2|3|4|5|6|718|9101I |2l3|4|5|6|7|6|9|0ll 12|3|4l5|6l7|8|9lQ|l |2|3|4|5|6|7f8|9|0|l I2l3|4|5l6|7|8|9l0|l |2|3|4|5|6|7|8l9|Q|l I2I3I4T5 


41-50 


51-60 


61- 


70 71-80 




x 


/,/ 


■■Ey.E,C. ,P,G|M-,I 


EYFORTACCT = (896? 427) iC0ND = (7iLT] 

I_I_I_1_1_I_1—1_I_I_I_I_1—1_I_I__1 C 1*1_1_I_I_ I I 1 I T 1 11 




1 1 I_111_I_I_1_I_I I 1 


J_I_1...._I I I .1. 


EY\QmpJe-\ & 


_J_I_I__I_I_I_L_ 


—i_i_i_j_L 


II 


STE.P4 EX.EC 


FO.RTECLG) 


J_I_i_l_I_ i i i _l_I_I_I_l_I_ 


II 


1 ..J_I_I__I_L 


PARM-FORT^DEOCMAPlUST' 


, [ . i i r r r 


/./ 




-1—L —J_L 1 I -L. 


, [PARM.Ep =,X RE,F) 


J_1_I - if _1—1_I_L_ 


/./ 


fiO,KI.D..,L.K.E.D.-,(7.).L.T l ).S.T.Em 


lll llll 


•imh 


n 


CO N D. ,6.0=. (. (|7L T ?, ST ,E P 4. 


_J_i. i 1..-L-J_L 


LKED)?(7iLT 

ii i i ii i i i ■ 


TEP4 

■ ■ 


F 0 


RT) 


b 


II 


_L_i_ 


l ACCT=,108LA, 


j _I_i_i_i_i_ 


—I_I_I_I_L_ 


I I 1 . 1 1 I 1 — 1 . 11 1 —I L—I L— 1 —J I L—J I 1—1 I L—J I I L 


■ L.i i 


Figure 6. Sample EXEC Statements 



i 


NAME FIELD 

The "stepname" is the name of the job 
step or procedure step. 


OPERAND FIELD 
Positional Parameter 

The options in the positional parameter 
of an EXEC statement specify either the 
name of the cataloged procedure or program 
to be executed. 

Each program (load module) to be execut¬ 
ed must be a member of a PDS. 

Specifying a Cataloged Procedure: 

{ PROC-cataloged-procedure-name ) 
cataloged-procedure-name 

indicate that a cataloged procedure is 
invoked. The "cataloged procedure 
name" is the name of the cataloged 
procedure. For example, 

// EXEC PROC=FORTGC 
or 

// EXEC FORTGC 

indicates that the cataloged procedure 
FORTGC is to be executed. 

Specifying a Program in a Library: 

PGM=program-name 

indicates that a program is executed. 
The "program name" is a member name of 
a load module in either the system 


library (SYS1.LINKLIB) or a private 
library. For example, 

// EXEC PGM=IEWL 

indicates that the load module ILrtL is 
executed. (A load module in a private 
library is identified to the operating 
system through the use of a JOBLIB DD 
statement. See the discussion con¬ 
cerning JOBLIB under "Data Definition 
(DD) Statement" in this section.) 


Specifying a Program Described in a Pre¬ 
vious Job Step: 

PGM=*.stepname.ddname 

indicates that the name of the program 
to be executed is taken from a DD 
statement of a previous job step. The 
* indicates the current job; 
"stepname" is the name of a previous 
step within tne current job; and 
"ddname" is the name of a DD statement 
within that previous job step. (The 
"stepname" cannot refer to a job step 
in another job.) The program referred 
to must be a member of a PDS. For 
example, in the statements, 

//MCLX JOB ,JOHNSMITH,CGND=(7,LT) 


//STEP4 EXEC PGM=IEWL 
//SYSLMOD DD DSNAME=MATH(ARCTAN) 


//STEP5 EXEC PGM=*.STLP4.SYSLMOD 
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statement STEP5 indicates that the 
name of the program is taken from the 
DD statement SYSLMOD in job step 
STEP4. Consequently, the load module 
ARCTAN in the PDS MATH is executed. 


Specifying a Program Described in a Cata¬ 
loged Procedure: 


PGM=*.stepname.procstep.ddname 

indicates that the name of the program 
to be executed is taken from a DD 
statement of a previously executed 
step of a cataloged procedure. The * 
indicates the current job; "stepname" 
is the name of the job step that 
invoked the cataloged procedure; 
"procstep" is the name of a step 
within the procedure; "ddname" is the 
name of a DD statement within the 
procedure step. (The "stepname" can¬ 
not refer to a job step in another 
job.) For example, consider a cata¬ 
loged procedure FORT, 


//COMPIL EXEC 

//SYSPRINT DD 
//SYSPUNCH DD 
//SYSLIN DD 


PGM=IEYFORT 
SYSOUT=A 
UNIT=SYSCP 
DSNAME=LINKINP 


//LKED EXEC 

//SYSLMOD DD 


PGM=IEWL 

DSNAME=RESULT(ANS) 


Furthermore, assume the following 
statements are placed in the input 
stream. 


//XLIV JOB ,SMITH,COND=(7,LT) 

//SI EXEC PROC=FORT 


//S2 EXEC 

//FT03F001 

//FT01F001 


PGM=*.SI.LKED.SYSLMOD 
DD UNIT=PRINTER 

DD UNIT=INPUT 


The statement S2 in the input stream 
indicates that the name of the program 
is taken from the DD statement SYSLMOD 
in the procedure step LKLD in the 
procedure FORT, which was invoked by 
the EXEC statement Si. Consequently, 
the loaa module ANS in the PDS RESULT 
is executed. 


Keyword Parameters 

The keyword parameters may refer to a 
program, to an entire cataloged procedure, 
or to a step within a cataloged procedure. 


i 




Options for the Compiler and Linkage Edi- 
tor: 


The PARM parameter is usea to pass 
options to the compiler or linkage editor. 
(PARM has no meaning to a FORTRAN load 
module.) 


PARM 


passes options to the compiler or 
linkage editor, when either is invoked 
by the PGM parameter in the EXeC 
statement, or to the first step in a 
cataloged procedure. 


PARM.procstep 

passes options to a compiler or link¬ 
age editor step within the named cata¬ 
loged procedure step. 


The format for compiler options, and 
those linkage editor options most applica¬ 
ble to the FORTRAN programmer is shown in 
Figure 7. 

Detail information concerning compiler 
and linkage editor options is given in the 
section "FORTRAN Job Processing." 


r 

| Compiler: 




| (PARM \ 

( LIST ) 


f, SOURCE ) 

j \parm. procstep;=( 

\ NOLIST f[,NAME=xxxxxx] 

[,LINECNT=xx] 

NOSOURCE j 


DECK \ /.MAP ) (,LOAD 

(, BCD \ ) 1 



NODECKj l,NOMAPf NOLOAD ),EBCDIC f 


jLinkage Editor: 




| (PARM ) 

[MAP 1 



j (PARM.procstepj=( 

L 

LXREFj[,LET] [,NCAL] 

[.LIST]) 1 


1 

I^The subparameters 

L 

(options) are keyword 

subparameters. 







Figure 7. Compiler and Linkage Editor Options 
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Condition for Bypassing a Job Step: 


DATA DEFINITION (DP) STATEMENT 


This COND parameter (unlike the one in 
the JOB statement) determines if the job 
step defined by the EXEC statement is 
bypassed , 

COND 

states (Conditions for bypassing the 
execution of a program or an entire 
cataloged procedure. 

COND.procstep 

states conditions for bypassing the 
execution of a specific cataloged pro¬ 
cedure step "procstep". 

The subparameters for the COND parameter 
are of the form: 

(code,operator[,stepname]) 

The subparameters "code" and "operator" 
are the same as the code and operator 
described for the COND parameter in the JOB 
statement. The subparameter "stepname" 
identifies the previous job step that 
issued the code. For example, the COND 
parameter 

COND=( (5 ,LT,FORT),(5,LT,LKED)) 

indicates that the step in which the COND 
parameter appears is bypassed if 5 is less 
than the code returned by either of the 
steps FORT or LKED. 

If a step in a cataloged procedure 
issued the code, "stepname" must qualify 
the name of the procedure step; that is, 

(code,operator[,stepname.procstep]) 

If "stepname" is not given, "code" is 
compared to all codes issued by previous 
job steps. 


Accounting Information: 

The ACCT parameter specifies accounting 
information for a job step within a job. 

ACCT 

is used to pass accounting information 
to the installation accounting rou¬ 
tines for this job step. 

ACCT.procstep 

is used to pass accounting information 
for a step within a cataloged proce¬ 
dure. 

If both the JOB and EXEC statements 
contain accounting information, the instal¬ 
lation accounting routines decide how the 
accounting information shall be used for 
the job step. 


The DD statement (Figure 8) describes 
data sets. The DD statement can contain 
the following information: 

1. Name of the data set to be processed. 

2. Type and number of I/O uevices for the 
data set. 

3. Volume(s) on which the data set 

resides. 

4. Amount and type of space allocated on 
a direct-access volume. 

5. Label information for the data set. 

6. Disposition of the data set after 
execution of the job step. 

7. Allocation of data sets with regard to 
channel optimization. 


NAME FIELD 

ddname 

is used: 

1. To identify data sets defined by 
this DD statement to the compiler 
or linkage editor. 

2. To relate data sets aefined by 
this DD statement to data set 
reference numbers used by the 
programmer in his source module. 

3. To identify this DD statement to 
other control statements in the 
input stream. 

The "ddname" format is given in "FORTRAN 

Job Processing." 

procstep.ddname 

is used to override DD statements in 
cataloged procedures. The step in the 
cataloged procedure is identified by 
"procstep." The "ddname" identifies 
either: 

1. A DD statement in the cataloged 
procedure that is to be modified 
by the DD statement in the input 
stream, or 

2. A DD statement that is to be 
added to the DD statements in the 
procedure step. 

JOBLIB 

is used to concatenate partitioned 
data sets with the system library; 
that is, the operating system library 
and the data sets specified in the 
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JOBLIB DD statement are temporarily 
combined to form one library. The 
JOBLIB statement must immediately fol¬ 
low a JOB statement, and the concate¬ 
nation is in effect only for the 
duration of the job. In addition, 
"DISP=(OLD,PASS)" must be specified in 
the JOBLIB DD statement. 

(See the following text concerning the 
DISP parameter.) Only one JOBLIB 
statement may be specified for a job. 

The "PGM=program name" parameter in 


the EXEC statement refers to a load 
module in the system library. Howev¬ 
er, if this parameter refers to a load 
module in a private library, a JOBLIB 
statement identifying the PDS in which 
the module resides must be specified 
for the job. The JOBLIB statement 
concatenates the system library with 
the private library. 


The library indicated in the JOBLIB 
statement is searched before the sys¬ 
tem library is searched. 


r- t- 

|Operation|Operand 1 


I Name 


1 

1 1 

ddnarne ", 

i 

2 i 

DD 

i 

i 


4 


procstep.ddnarne 

i 


i 

DUMMY 


1 1 
1 

[jOBLIB 3 j 

i j 

i 


i 

DATA 



h 


Positional Parameter 


Keyword Parameters - 


DDNAME=ddname 

dsname 

dsname(element) 

* . ddnarne 

DSNAME= ^*.stepname.ddnarne 

*.stepname.procstep.ddnarne 
fcname 

Sname(element) 

(UNIT=(subparameter-list) ] 

[DCB=(subparameter-list) ] 

[VOLUME=(subparameter-list)] 


SPACE=(subparameter-list) 
SPLIT=(subparameter-list) 
SUBALLOC=(subparameter-list) 

[LABEL=(subparameter-list)] 

[ DISP= (subparameter-list)~| 
SYSOUT=A J 

[SEP=(subparameter-list)] 


H 


*A DD statement with a blank operand field can be used to override parameters specified 
in cataloged procedures. (See "Overriding and Adding DD Statements" in the section 
"Cataloged Procedures".) 

2 The name field is blank when concatenating data sets. (Note the exception for the use 
of JOBLIB.) 

3 The JOBLIB statement precedes any EXEC statements in the job. (See the discussion 
concerning JOBLIB under "Name Field" in this section.) 

^If the positional parameter is specified, keyword parameters cannot be specified. 

5 If "subparameter-list" consists of only one subparameter and no leading comma 
(indicating the omission of a positional subparameter) is required, the delimiting 
parentheses may be omitted. 


Figure 8. Data Definition Statement 
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Note: A JOBLIB statement does not have 
to be entered for load modules created 
in this job, or for permanent members 
of the system library. 

Blank Name Field 

If the name field is blank, the data 
set defined by the DD statement is 
concatenated with the data set defined 
in the preceding DD statement. In 
effect, these two data sets are com¬ 
bined into one data set. Other parti¬ 
tioned data sets (not individual mem¬ 
bers of a PDS) may also be concatenat¬ 
ed with the data set specified in the 
JOBLIB DD statement. Therefore, the 
system library may be concatenated 
with several partitioned data sets. 

Note : In concatenation of data sets, 
neither of the designated data sets 
may be in the input stream. Also, 
data sets whose records are of differ¬ 
ent length and/or different formats 
cannot be concatenated. 


OPERAND FIELD 

For purposes of discussion, parameters 
for the DD statement are divided into seven 
functions: 

• Specify data in the input stream. 

• Specify unit record data sets. 

• Retrieve a previously created and cata¬ 
loged data set. 

• Retrieve a data set which was created 
in a previous job step in the current 
job and passed to the current job step. 

• Retrieve a data set created but not 
cataloged in a previous job. 

• Create data sets that reside on magnet¬ 
ic tape or direct-access volumes. 


|data| 


DSNAME= 


dsname 

dsname(element) 

*.ddname 

*.stepname. ddname 
*.stepname.procsttp.ddname \ 
6 name 

Sname(element) 


UNIT=(name[,(n|P} 2 ]) 3 


PRTSP=0 
PRTSP=1 
PRTSP=2 
DCB=(/ l PRTSP=3 


( fMODE=E ) ( STACK~1 ^ ) 
1 (MODE=C J (, STACK=2j ( 

f SYSOUT=A 


C OLD | 
lDISP=( < NEW> 
r ( JViOD ) 


', DELETE 
, KEEP 
, PASS 
,CATLG 
,UNCATLG 


) 5 


LABEL=(subparameter-list) 6 
VOLUME=(subparameter-list) 6 


^If either of these two parameters is 
selected, it must be the only parameter 
selected. 

2 If neither "n" nor "P" is specified, 1 
is assumed. 

3 If only "name" is specified, the delim¬ 
iting parentheses may be omitted. 

4 The assumption for the second subparam¬ 
eter is discussed in "Specifying the 
Disposition of a Data Set" in this 
section. 

5 The subparameters are positional. 

6 See the section "Creating Data Sets." 


Figure 9. DD Statement 


• Optimize I/O operations. 

The following text describes the DD 
statement parameters that apply to: 

1. Processing unit record data sets. 


Parameters shown in Figure 8 and not 
mentioned in this section are used to 
create data sets and optimize I/O opera¬ 
tions in job steps. These parameters are 
discussed in the sections "Creating Data 
Sets" and "Programming Considerations." 


2. Retrieving data sets created in pre¬ 
vious job steps. 

3. Retrieving data sets created and cata¬ 
loged in previous jobs. 

See Figure 9 for applicable parameters. 

The method of retrieving uncataloged 
data sets created in previous jobs is also 
discussed in this section. 


Specifying Data in the Input Stream: 

* 

indicates that a data set (e.g., a 
source module or data), immediately 
follows this DD statement in the input 
stream (see Figure 10). If the EXEC 
statement for the job step invokes a 
cataloged procedure, a data set may be 
placed in the input stream for each 
procedure step. If the EXEC statement 
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Figure 10, Examples of DD Statements for Unit Record Devices 


specifies execution of a program, only 
one data set may be placed in the 
input stream. The DD * statement must 
be the last DD statement for the 
procedure step or program. The end of 
the data set must be indicated by a 
delimiter statement. The data cannot 
contain // or /* in the first two 
characters of a record. 

DATA 

also indicates data in the input 
stream. The restrictions and use of 
the DATA parameter are the same as the 
*, except that // may appear in the 
first and second positions in a 
record. 

UNIT Parameter: 


aounle space, and triple space, re¬ 
spectively. This subparameter is not 
effective if A (for ASA carriage con¬ 
trol characters) has been specified in 
the RECFJYi parameter (refer to the 
paragraph on Record Format in the 
section "Creating Data Sets"). 

i M0DE=E \jf, STACKS 1 ) 

DCB= ( (MODE=C / l, STACK=2 f ) 

specify options for the card read 
punch. The KODE subparaireter indi¬ 
cates whether the card is transmitted 
in column binary mode (C) or EBCDIC 
mode (E). 

The STACK subparameter indicates a 
stacker selection for the card read 
punch. 


UNJT=(name[,{n|P>]) 

specifies the name and number of I/O 
devices for a data set (see Figure 
10). When the system is generated, 
the "name" is assigned by the operat¬ 
ing system or the installation and 
represents a device address, a device 
type, or a device class. (See the 
System Generation publication.) The 
programmer can use only the assigned 
names in his DD statements. For exam¬ 
ple, 

UNIT=19 0, UNIT=2311, UNIT=TAPE 

where 190 is a device address, 2311 is 
a device type, and TAPE is a device 
class. 

n | P 

specifies the number of devices allo¬ 
cated to the data set. If a number 
"n" is specified, the operating system 
assigns that number of devices to the 
data set. Parallel, "P" , is used with 
cataloged data sets when the requireu 
number of volumes is unknown. The 
control program assigns a device for 
each volume required for the data set. 

DCB Parameter: 

DCB—PRTSP={0|112 j 3} 

is used to indicate line spacing for 
the printer. Tne digits 0, 1, 2, and 
3 indicate no space, single space. 


SYSQUT Parameter; A SYSOUT parameter may 
be specified for printer data sets. 

SYSOUT=A 

indicates the device class A for the 
data set. The data set aefinea by the 
DD statement that contains the SYSOUT 
parameter is written on a device cho¬ 
sen by the operator. (See the 
Operator's Guide .) No parameter other 
than the DCB parameter has any meaning 
when the SYSOUT parameter is used. 

Retrieving Previously reated Data Sets 

If a data set is created with standard 
labels and cataloged in a previous jon, all 
information for the data set, such as 
record format, density, volume sequence 
number, device type, etc., is stored in the 
catalog and labels. This information need 
not be repeated in the DD statement used to 
retrieve the data set; only the name 
(DSNAKE) and disposition (DISP) is 
required. 

If a data set was created in a previous 
job step in the current job, all the 
information in the previous DD statement is 
available to the control program, and is 
accessible by referring to tne previous DD 
statement by name. To retrieve the data 
set, a pointer to a data set created in a 
previous job step is specified by the 
DSNAME parameter. The disposition (DISP) 
of the data set is also specified. 
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If a data set is created with standard 
labels in a previous job but was not 
cataloged, information pertaining to the 
data set, such as record format, density, 
volume sequence number, etc., is stored in 
the label; the device type information is 
not stored. To retrieve the data set, the 
name (DSNAME), disposition (DISP), volume 
serial number* (VOLUME) , and device (UNIT) 
must be specified. 

If a data set is created with no labels 
and cataloged, device type information is 
stored in the catalog. To retrieve the 
data set, the name (DSNAME), disposition 
(DISP), volume serial number (VOLUME), 
LABEL and DCB parameters must be specified. 

Examples of the use of DD statements to 
retrieve previously created data sets are 
shown in Figure 11. 

IDENTIFYING A CREATED DATA SET: The DSNAME 
parameter indicates the name of a data set 
or refers to a data set defined in the 
current or a previous job step. 

Specifying a Cataloged Data Set by Name: 

DSNAME=dsname 

the fully qualified name of the data 
set is indicated by "dsname." If the 
data set was previously created and 
cataloged, the control program uses 
the catalog to find the data set and 
instructs the operator to mount the 
required volumes. 

Specifying a Generation Data Group or PDS: 

DSNAME=dsname(element) 

indicates either a generation data set 
contained in a generation data group, 
or a member of a partitioned data set. 


The name of the generation data group 
or partitioned data set is indicated 
by "dsname”; if "element" is either 0 
or a signed integer, a generation data 
set is indicated. For example. 


DSNAME=FIRING(-2) 


indicates the thirdmost recent member 
of the generation data group FIRING. 
(See the Data Management publication 
for a description of generation data 
sets.) If "element" is a name, a 
member of a partitioned data set is 
indicated. 


Referring to a Data Set in the Current Job 
Step: 

DSNAME=*.ddname 

indicates a data set that is defined 
previously in a DD statement in this 
job step. The * indicates the current 
job. The name of the data set is 
copied from the DSNAME parameter in 
the DD statement named "ddname." 


Referring to a Data Set in a Previous Job 
Step: 

DSNAME=*.stepname.ddname 

indicates a data set that is defined 
in a DD statement in a previous job 
step in this job. The * indicates the 
current job, and "stepname" is the 
name of a previous job step. The name 
of the data set is copied from the 
DSNAME parameter in the DD statement 
named "ddname." For example, in the 
control statements: 
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Figure 11. Retrieving Previously Created Data Sets 
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//LAUNCH JOB 

//JOBLIB DD DSNAME=FIRING,DISP=(OLD,PASS) 
//SI EXEC PGM=ROCKET 
//FT01F001 DD DSNAME=RATES(+1) 

//FT09F001 DD DSNAME=TIME,DISP=(OLD,PASS) 
//S2 EXEC PGM=DISTANCE 

//FT08F001 DD DSNAME=*.Si•FT09F001, 1 

// DISP=OLD 

//FT05F001 DD * 


The DD statement FT08F001 in job step 
S2 indicates that the data set name 
(TIME) is copied from the DD statement 
FT09F001 in job step Si. 

Referring to a Data Set in a Cataloged 

Procedure; 

DSNAME=*.stepname.procstep.ddname 

indicates a data set that is defined 
in a cataloged procedure invoked by a 
previous job step in this job. The * 
indicates the current job; "stepname" 
is the name of a previous job step; 
"procstep" is the name of a step in 
the cataloged procedure. The name of 
the data set is copied from the DSNAME 
parameter in the DD statement named 
"ddname." 

Assigning Names to Temporary Data Sets: 

DSNAME= £name 

assigns a name to a temporary data 
set. The control program assigns the 
data set a unique name which exists 
only until the end of the current job. 
The data set is accessible in subse¬ 
quent job steps by specifiying 
"Sname." If it is required to refer 
to this name in a separate job (i.e., 
because of abnormal termination) the 
name is "£name.JOBNAME." 

DSNAME=6name(element) 

assigns a name to a member of a 
temporary PDS. The name is assigned 
in the same manner as the 
"DSNAME= & name." If it is required to 
refer to this name in a separate job 
(i.e., because of abnormal 

termination) the name is 

"6name.JOBNAME." 


SPECIFYING THE DISPOSITION OF A DATA SET; 
The DISP parameter is specified for both 
previously created data sets and data sets 
created in this job step. 


is used for all data sets residing on 
magnetic tape or direct access volumes. 

The first subparameter indicates when 
the data set is (was) created. 

NEW 

indicates that the data set is created 
in this step. NEW is discussed in 
more detail in the section "Creating 
Data Sets." 

OLD 

indicates that tne data set was creat¬ 
ed by a previous job or job step. 

MOD 

indicates that the data set was creat¬ 
ed in a previous job or job step, but 
records can be added to the data set. 
Before the first I/O operation for the 
data set occurs, the data set is 
positioned after the last record. If 
MOD is specified and (1) the volume 
serial number is omitted, and (2) the 
data set is not cataloged or passed, 
then MOD is ignored and NEW assumed. 

The second subparameter indicates the 
disposition of the data set. 

DELETE 

causes the space occupied by the data 
set to be released and made available 
at the end of the current job step. 
If the data set was cataloged, it is 
removed from the catalog. 

KEEP 

insures that the data set is kept 
intact until a DELETE option is speci¬ 
fied in a subsequent job or job step. 
KEEP is used to retain uncataloged 
data sets for processing in future 
jobs. KEEP does not imply PASS. 

PASS 

indicates that the data set is 
referred to in a later job step. When 
a subsequent reference to the data set 
is made, its PASS status lapses unless 
another PASS is issued. The final 
disposition of the data set should be 
stated in the the last job step that 
uses the data set. When a data set is 
in PASS status, the volume(s) on which 
it is mounted is retained. If dis¬ 
mounting is necessary, the control 
program issues a message to mount the 
volume(s) when needed. PASS is used 
to pass data sets among job steps in 
the same job. 


(NEW ) 
DISP=(\OLD> 

(mod) 


,DELETE 
, KEEP 

,PASS ) 
, CAT LG 
,UNCATLG 


If a data set on an unlabeled tape is 
being passed, the volume serial number 
must be specified in the VOLUME=SER= 
parameter of the DD statement that 
"passed" the data set. 
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DELIMITER STATEMENT 





Note; The PASS status of the private 
library specified in a JOBLIB DD 
statement always remains in effect for 
the duration of a job. 

CATLG 

causes the creation of a catalog entry 
that points to the data set. The data 
set can then b6 referred to in subse¬ 
quent jobs or job steps by name (CATLG 
implies KEEP). 

UNCATLG 

causes references to the data set to 
be removed from the catalog at the end 
of the job step. 

If the second subparameter is not speci¬ 
fied, no action is taken to alter the 
status of the data set. If the data set 
was created in this job, it is deleted at 
the end of the current job step. If the 
data set existed prior to this job, it 
remains in existence at the end of the job. 


The delimiter statement (see Figure 12) 
is used to separate data from subsequent 
control statements in the input stream, and 
is placed after each data set in the input 
stream. It cannot be placed in a catalog 
procedure. 


r- t-t- 1 

|Name |Operation|Operand | 

h-+-+-1 

|/* I I I 

L-X-X-J 

Figure 12. Delimiter Statement 


The delimiter statement contains a slash 
in column 1, an asterisk in column 2, and a 
blank in column 3. The remainder of the 
card may contain comments. 
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FORTRAN JOB PROCESSING 


A FORTRAN source module may be processed 
starting with compilation and ending with 
execution. In this case three steps are 
required: compile the source module to 
obtain an object module, link edit the 
object module to obtain a load module, and 
execute the load module. Job control 
statements are required for each of these 
steps to: indicate the program or procedure 
to be executed, to specify options for the 
compiler and linkage editor, to specify 
conditions for termination of processing, 
and to define the data sets used during 
processing- Because writing these job con¬ 
trol statements can be time-consuming work 
for the programmer, IBM supples four cata¬ 
loged procedures to aid in the processing 
of FORTRAN modules. The use of cataloged 
procedures minimizes the number of job 
control statements that must be supplied by 
the programmer. 


Figure 13 shows control statements that 
can be used to invoke FORTGC. The SYSIN 
data set containing the source module is 
defined as data in the input stream for the 
compiler. Note that a delimiter statement 
follows the FORTRAN source module. 


//jobname JOB 
// EXEC FORTGC 
//FORT.SYSIN DD * 


r - 1 

| FORTRAN Source Module j 

L_J 


/* 

Figure 13. Invoking the Cataloged Proce¬ 
dure FORTGC 



USING CATALOGED PROCEDURES 

When a programmer uses cataloged proce¬ 
dures, he must supply the following job 
control.statements: 

1. A JOB statement. 

2. An EXEC statement that indicates the 
cataloged procedure to be executed. 

3. A procstep.SYSIN DD statement that 
specifies the location of the source 
module(s) or the object module(s) to 
the control program. 

Note: If the source module(s) and/or 

object module(s) are placed in the input 
stream, a delimiter statement is required 
at the end of each data set. 


Single Compile: A sample deck structure to 
compile a single source module is shown in 
Figure 14. 


//JOBSC JOB 00,FORTRANPROG,MSGLEVEL^l 
//EXECC EXEC PROC=FORTGC 
//FORT.SYSIN DD * 


r- 1 

| FORTRAN Source Module | 

L_J 


/* 


Figure 14. Compiling a Single Source 
Module 


Batched Compile: A sample deck structure 

to batch compile is shown in Figure 15. 


In addition, a GO.SYSIN DD * statement 
can be used to define data in the input 
stream for load module execution. (A de¬ 
limiter statement is also required at the 
end of this data.) 

The job control statements needed to 
invoke the procedures, and deck structures 
used with the procedures are described in 
the following text. 


COMPILE 

The cataloged procedure for compilation 
is FORTGC. This cataloged procedure con¬ 
sists of the control statements shown in 
Figure 43 in "Cataloged Procedures." 


//JOBBC JOB 00,FORTRANPROG,MSGLEVEL=1 
//EXECC EXEC PROC=FORTGC 
//FORT.SYSIN DD * 

r- 1 

| First FORTRAN Source Module | 

L_J 


r - 1 

| Last FORTRAN Source Module | 

L-J 


/* 


Figure 15. Compiling Several Source 

Modules 



i 
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When several source modules are entered 
in the SYSIN data set for one job step, the 
compiler recognizes the FORTRAN END state¬ 
ment. If the next card is a delimiter 
statement, the control program is called at 
the end of the compilation. If the next 
card is a FORTRAN statement, the FORTRAN 
compiler remains as the controlling pro¬ 
gram. 


COMPILE AND LINK EDIT 

The cataloged procedure to compile FOR¬ 
TRAN source modules and link edit the 
resulting object modules is FORTGCL. This 
cataloged procedure consists of the control 
statements shown in Figure 44 in "Cataloged 
Procedures." 


Figure 16 shows control statements that 
can be used to invoke FORTGCL. 


//jobname JOB 
// EXEC FORTGCL 
//FORT.SYSIN DD * 


r-1 

| FORTRAN Source Module | 

L-J 


/* 

Figure 16. Invoking the Cataloged Proce¬ 
dure FORTGCL 


//JOBBLG JOB 00,FORTPROG,MSGLEVEL=1 
//EXECLG EXEC PROC=FORTGLG 
//LKED.SYSIN DD * 

I*- 1 

| First FORTRAN Object Module | 

i_j 


r- 1 

| Last FORTRAN Object Module 

L-J 

/* 

//GO.SYSIN DD * 

r- 1 

| Data | 

L-J 

/* 


Figure 18. Link Edit and Execute Several 
Object Modules in the Input 
Stream 


The object module decks were created by 
the DECK compiler option. The linkage 
editor recognizes the end of one module and 
the beginning of another, and resolves 
references between them. 


Figure 19 illustrates a sample deck 
structure that link edits and executes 
object modules that are members of the 
cataloged sequential data set, OBJMODS, as 
a single load module. Reading of a data 
set in the input stream is accomplished by 
using data set reference number 5. 


LINK EDIT AND EXECUTE 

The cataloged procedure to link edit 
FORTRAN object modules and execute the 
resulting load module is FORTGLG. This 
cataloged procedure consists of the control 
statements shown in Figure 45 in "Cataloged 
Procedures." 

Figure 17 shows control statements that 
can be used to invoke FORTGLG. 


//jobname JOB 
// EXEC FORTGLG 
//LKED.SYSIN DD * 


r- 1 

| FORTRAN Object Module 

L_J 


/* 

Figure 17. Invoking the Cataloged Proce¬ 
dure FORTGLG 


Figure 18 illustrates a sample deck 
structure to link edit and execute several 
object modules in the input stream as one 
load module. 


//JOBBLG JOB 00,FORTPRGG,MSGLEVEL=1 
//EXECLG EXEC FORTGLG 

//LKED.SYSIN DD DSNAME=OBJMODS,DISP=OLD 
//GO.SYSIN DD * 

r 1 

| Data j 

l -j 

/* 

Figure 19. Link Edit and Execute Several 
Object Modules in a Cataloged 
Data Set 


COMPILE, LINK EDIT, AND EXECUTE 

The fourth cataloged procedure, 
FORTGCLG, passes a source module through 
three procedure steps: compile, link edit, 
and execute. This cataloged procedure con¬ 
sists of the control statements shown in 
Figure 46 in "Cataloged Procedures." 


Figure 20 shows control statements that 
can be used to invoke FORTGCLG. 


Fortran Job Processing 
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//jobnaroe JOB 
// EXEC PROC=FORTGCLG 
//FORT.SYSIN DD * 


r- 1 

| FORTRAN Source Module | 

L_J 

/* 


Figure 20. Irivoking the Cataloged Proce¬ 
dure FORTGCLG 


Single Compile, Link Edit, and Execute: 
Figure 21 shows a sample deck structure to 
compile, link edit, and execute a single 
source module. 


COMPILER PROCESSING 

The names for DD Statements (ddnames) 
relate I/O statements in the compiler with 
data sets used by the compiler. These 
ddnames must be used for the compiler. 
When the system is generated, names for I/O 
devices classes are also established and 
must be used by the programmer. 

Compiler Name 

The program name for the compiler is 
IEYFORT. If the compiler is to be executed 
without using the supplied cataloged proce¬ 
dures in a job step, an EXEC statement of 
the form 


//JOBSCLG JOB 00,FORTPROG,MSGLEVEL=1 
//EXECC EXEC FORTGCLG 
//FORT.SYSIN DD * 


r - 1 

FORTRAN Source Module 

L_J 

/* 

//GO.SYSIN DD * 

r- 1 

| Data | 

l_J 

/* 


Figure 21. Single Compile, Link Edit, and 
Execute 

Batched Compile, Link Edit, and Execute: 
Figure 22 shows a sample deck structure to 
batch compile, link edit, and execute. The 
source modules are placed in the input 
stream along with a data set that is read 
using data set reference number 5. 


//JOBBCLG JOB 00,FORTPROG,MSGLEVEL=1 
//EXECCLG EXEC FORTGCLG 
//FORT.SYSIN DD * 


r- i 

| First FORTRAN Source Module | 

L_J 


f-1 

| Last FORTRAN Source Module | 

L_J 

/* 

//LKED.SYSIN DD * 

r-1 

Object Modules | 

l_j 

/* 

//GO.SYSIN DD * 

r- 1 

j Data | 

l_J 

/* 


// EXEC PGM=IEYFORT 


must be used. (For more detailed informa¬ 
tion on procedures and options in calling 
IEYFORT, refer to Appendix A, "Invoking the 
FORTRAN Compiler.") 

Compiler ddnames 

The compiler can use four data sets. To 
establish communication between the compil¬ 
er and the programmer, each data set is 
assigned a specific ddname. Each data set 
has a specific function and device require¬ 
ment. Table 2 lists the ddnames, func¬ 
tions, and device requirements for the data 
sets.. 


Table 2. Compiler ddnames 


-T- 

I 

ddname |FUNCTION 


DEVICE 

REQUIREMENTS 


h- 


SYSIN j reading the 
j source 
j program 


•card reader 
•magnetic tape 
•direct-access 


h 


SYSPRINTjwriting the 
|storage 
I reap, 

(listing, and 
jmessages 


•printer 
•magnetic tape 
•direct-access 


h 


SYSPUNCH j punching 

jthe object 
|module deck 


•card punch 1 
•magnetic tape 
•direct-access 


h 


SYSLIN |output data 
)set for the 
[object module 
[Used as input 
jto the link- 
jage editor 


•direct-access 
•magnetic tape 
•card punch 1 


1 These must not 
devices 


be same card punch 


Figure 22. Batched Compile, Link Edit, and 
Execute 


To compile a FORTRAN source module, two 
of these data sets are necessary; SYSIN and 
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SYSPRINT, along with the direct-access 
volume(s) that contains the operating sys¬ 
tem. With these two data sets, only a 
listing is generated by the compiler. If 
an object module is to be punched and/or 
written on a direct-access or magnetic tape 
volume, a SYSPUNCH and/or SYSLIN DD state¬ 
ment must be supplied. 

For the DD statement SYSIN or SYSPRINT, 
an intermediate storage device (direct- 
access or magnetic tape) may be specified 
instead of the card reader or printer. 

If an intermediate device is specified 
for SYSIN, the compiler assumes that the 
source module deck was written on inter¬ 
mediate storage by a previous job or job 
step. If an intermediate device is speci¬ 
fied for SYSPRINT, the map, listing, and 
error/warning messages are written on that 
device; a new job or job step can print the 
contents of the data set. When the SYS¬ 
PRINT data set is written on an intermedi¬ 
ate storage device, carriage control char¬ 
acters are placed in the records. 


The data sets used by the compiler must 
be assigned to the device classes listed in 
Table 4. 


Table 4. Correspondence Between Compiler 
ddnames and Device Classes 


r- T - 

|ddname |Possible Device Classes 

F-+- 

|SYSIN |SYSSQ, or the input stream de- 

j |vice (specified by DD * or DD 

|DATA), or a device specified 
j | as a card reader 

f-+-- 

| SYSPRINT|A,SYSSQ 

F-+- 

|SYSPUNCH|SYSCP 

F-1- 

| SYSLIN |SYSSQ,SYSDA 

L--L- 


I 

I 

I 

I 

I 

-\ 

I 


Compiler Options 

Options may be passed to the compiler 
through the PARM parameter in the EXEC 
statement (see Figure 23). The following 
information may be specified: 


Compiler Device Classes 

Names for input/output device classes 
used for compilation are also specified for 
the operating system when the system is 
generated. The class names, functions, and 
types of devices are shown in Table 3. 


1. Whether a listing of an object module 
is printed. 

2. Name assigned to the program. 

3. The number of lines per page for the 
source listing. 


Table 3. Device Class Names 


jCLASS NAME 

F- 

SYSSQ 


_ T - T --I 

(CLASS FUNCTIONS|DEVICE TYPE | 
- +-+-j 


j writing, 
j reading, 
j backspacing 
j(sequential) 


•magnetic 

tape 

•direct- 

access 


SYSDA jwriting, 

j reading, 
j backspacing, 
j updating 
j records in 
(place (direct) 


•direct- 

access 


SYSCP 


(punching cards 

-+- 

|SYSOUT output 

I 

I 

_x_ 


•card punch 


•printer 

•magnetic 

tape 


4. Whether the source module is coded in 
Binary Coded Decimal (BCD) or Extended 
Binary Coded Decimal Interchange Code 
(EBCDIC). 

5. Whether a list of the source state¬ 
ments, with their associated internal 
statement numbers, is printed. 

6. Whether an object module is punched. 

7. Whether a storage map of variable 
names used in the source module is 
printed. 

8. Whether the compiler writes the object 
module on external storage for input 
to the linkage editor. 


Options specified in the PARM parameter 
may be in any order. 


\ (PARM ) (LIST ) (,BCD ) (, SOURCE ) 

j (PARM.procstepf=(1 NOLIST f [,NAME = xxxxxxl [ ,LINECNT=xx3 , 1, EBCDIC H,NOSOURCEf 

,DECK / \,MAP ) | # LOAD ! 

, NODECK j j, NOMAP \ ],NOLOADp 


Figure 23. Compiler Options 
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LIST or NQLIST; The LIST option indicates 
that the object module listing is written 
on the data set specified by the SYSPRINT 
DD card. (The statements in the object 
module listing are in a pseudo assembly 
language format.) The NOLIST option indi¬ 
cates that no object module listing is 
written. A description of the object 
module listing is given in the section 
"System Output." 


Name=xxxxxx: The NAME option specifies the 
name (xxxxxx) assigned to a module (main 
program only) by the programmer. If NAME 
is not specified or the main program is not 
the first module in a compilation, the 
compiler assumes the name MAIN for the main 
program. The name of a subprogram is 
always specified in the SUBROUTINE or FUNC¬ 
TION statement. 

The name appears in the source listing, 
map, and object module listing. (See 
"Multiple Compilation Within a Job Step" in 
this section for additional considerations 
concerning the NAME option.) 


LINECNT-xx: The LINECNT option specifies 
the number (xx) of lines that will be 
written on the data set specified by the 
SYSPRINT DD statement when a source listing 
is generated by the compiler. The speci¬ 
fied number, xx, may be anywhere in the 
range from 1 to 99. If LINECNT is not 
specified, the number of lines will be 
obtained from the system (the default num¬ 
ber may be changed by the installation). 


BCD or EBCDIC; The BCD option indicates 
that the source module is written in Binary 
Coded Decimal; EBCDIC indicates Extended 
Binary Coded Decimal Interchange Code. 
Intermixing of BCD and EBCDIC in the source 
module is not allowed. 


Note; If the EBCDIC option is selected, 
statement numbers passed as arguments must 
be coded as 

&n 

However, if the BCD option is selected, 
statement numbers passed as arguments must 
be coded as 

$n 

and the $ must not be used as an alphabetic 
character in the source module. (n rep¬ 
resents the statement number.) 

SOURCE or NOSOURCE: The SOURCE option 
specifies that the source listing is writ¬ 
ten on the data set specified by the 


SYSPRINT DD statement. The NOSOURCE option 
indicates that the source listing is not 
written. A description of the source list¬ 
ing is given in the section "System 
Output." 


DECK or NODECK; The DECK option specifies 
that an object module card deck is punched 
as specified by the SYSPUNCH DD statement. 
The object module deck can be used as input 
to the linkage editor in a subsequent job. 
NODECK specifies that the object module 
deck is not punched. A description of the 
deck is given in the section "System Out¬ 
put." 


MAP or NOMAP: The MAP option specifies 
that a table of names, which appear in the 
object module, is written on the data set 
specified by the SYSPRINT DD statement. 
The type and location of each name is 
listed. The NOMAP option specifies that 
the table of names is not written. A 
description of the map is given in the 
section "System Output." 


LOAD or NOLOAD; The LOAD option indicates 
that the object module is written on the 
data set specified by the SYSLIN DD state¬ 
ment. This option must be used if the 
cataloged procedure to compile and link 
edit, or to compile, link edit, and execute 
is used; i.e., the object module is used as 
input to the linkage editor in the current 
job. 


The NOLOAD option indicates that the 
object module is not written on external 
storage. This option can only be used if 
the cataloged procedure to compile is used. 


Note; The compiler default options shown 
in this publication are standard IBM 
defaults; however, .at system generation, an 
installation can choose its own set of 
default options. 


Multiple Compilation Within a Job Step 

Several compilations may be performed 
within one job step. The compiler recog¬ 
nizes the FORTRAN END statement in a source 
deck, compiles the program, and determines 
if another source module follows the END 
statement. If there is another source 
module, another compilation is initiated 
(see Figure 24). 

Only one EXEC statement may be used to 
initiate a job step; therefore, compiler 
options can be stated only once for all 
compilations in a job step. 
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r -1 

| //JOBRA JOB , •FORTRAN PROG' | 
| //STEP1 EXEC FORTGC j 
| //FORT•SYSIN DD * j 
| 1 READ (8,10)A,B,C | 


END 

SUBROUTINE CALC 


| END | 

|/* I 

L_J 

Figure 24. Multiple Compilation Within a 
Job Step 


r- t- 1 

| Object Module 1 | Object Module 2 | 

L_J._J 


LINKAGE EDITOR PROCESSING 

The linkage editor processes FORTRAN 
object modules, resolves any references to 
subprograms, and constructs a load module. 
Communication with the linkage editor is 
established through a programmer supplied 
EXEC statement and DD statements that 
define all required data sets. The user 
also has the option of supplying linkage 
editor control statements. 

Linkage Editor Name 


The first main program in a multiple 
compilation is given the name specified in 
the NAME option (only if this program is 
not preceded by a SUBROUTINE or FUNCTION 
subprogram); all subsequent main programs 
are given the name MAIN. However, if the 
NAME option is not specified, only those 
main programs that are physically first in 
a multiple compilation are given the name 
MAIN. For example: in the multiple* compi¬ 
lation, 

//MULCOM JOB 

// EXEC FORTHC,PARM.FORT='NAME=IOR' 

//FORT.SYSIN DD * 

READ(1,10)ALP,BETA 


END 

SUBROUTINE INVERT(A,B) 


END 

READ(5)P,Q,R 


END 

/* 

The first main program is given the name 
IOR; the third program is given the name 
MAIN. The second program is assigned the 
name INVERT. However, had the order of the 
first two programs been reversed, the name 
IOR would not have been applied to any of 
the programs illustrated. 

When a multiple compilation is per¬ 
formed, the SYSLIN data set contains all 
the object modules because only one SYSLIN 
DD statement is supplied for compiler out¬ 
put. If tape or direct-access output is 
specified for the compiler, the object 
modules are written sequentially on the 
volume. 


Four linkage editor programs are availa¬ 
ble with the operating system. The program 
names for the four linkage editors and the 
minimum storage in which they are designed 
to operate are: 


IEWLE150 
IEWLE180 
IEWLF440 
IEWLF88 0 


15,360 bytes 
18,432 bytes 
45,056 bytes 
90,112 bytes 


All facilities described for the linkage 
editor in this publication are available 
with all four linkage editors, except that 
blocking the primary input is only availa¬ 
ble with the higher-level linkage editors, 
IEWLF440 and IEWLF88 0. 


For simpler programming, the linkage 
editors have been assigned the alias pro¬ 
gram name IEWL. If the programmer speci¬ 
fies the parameter 

PGM=IEWL 

in the EXEC statement, the highest level 
linkage editor provided in the 
installation's operating system is execut¬ 
ed. If he wants to execute a specific 
linkage editor, he must specify the specif¬ 
ic program name of that linkage editor. 

Linkage Editor Input and Output 

There are two types of input to the 
linkage editor: primary and secondary. 

Primary input is a sequential data set 
that contains object modules and linkage 
editor control statements. (A member of a 
PDS cannot be the primary input.) Any 
external references among object modules in 
the primary input are resolved by the 
linkage editor as the primary input is 
processed. Furthermore, the primary input 
can contain references to the secondary 
input. These references are linkage editor 
control statements ana/or FORTRAN external 
references in the object modules. 
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Secondary input resolves any references 
and is separated into two types: automatic 
call library and additional input specified 
by the programmer. The automatic call 
library should always be the FORTRAN 
library (SYSl.FORTLIB), which contains the 
FORTRAN library subprograms. Through the 
use of DD statements, the automatic call 
library can be cdncatenated with other 
partitioned data sets. Three types of 
additional input may be specified by the 
programmer: 

• An object module used as the main 
program in the load module being con¬ 
structed. This object module, which 
can be accompanied by linkage editor 
control statements, is either a member 
of a PDS or is a sequential data set. 
The first record in the primary input 
data set must be a linkage editor 
INCLUDE control statement that tells 
the linkage editor to insert the main 
program. 

• An object module or a load module used 
to resolve external references made in 
another module. An object module, 
which can be accompanied by linkage 
editor control statements, is a sequen¬ 
tial data set or is a member of a PDS. 
A load module, which is a member of a 
PDS, cannot be accompanied by linkage 
editor control statements. An INCLUDE 
statement that defines the data set 
must be given. 

• A load module used to resolve external 
references made in another module. The 
load module or object module, which can 
be accompanied by linkage editor con¬ 
trol statements, is a member of PDS. A 
linkage editor LIBRARY control state¬ 
ment that defines the data set to the 
linkage editor must be given. 


In addition, the secondary input can con¬ 
tain external references and linkage editor 
control statements. The automatic call 
library and any of the three types of 
additional input may be used to resolve 
references in the secondary input. 

The loaa module created by the linkage 
editor is always placed in a PDS. Error 
messages and optional diagnostic messages 
are written on an intermediate storage 
device or a printer. In addition, a work 
data set is required by the linkage editor 
to do its processing. Figure 25 shows the 
I/O flow in linkage editor processing. 


SYSUT 1 



Figure 25. Linkage Editor Input and Output 
Linkage Editor ddnames and Device Classes 

The programmer communicates data set 
information to the linkage editor through 
DD statements identified by specific 
ddnames (similar to the ddnames used by the 
compiler). The ddnames, functions, ana 
requirements for data sets are shown in 
Table 5. 

All data sets specified by SYSLIB or 
SYSLMOD must be partitioned data sets. 


Table 5. Linkage Editor ddnames 


ddname 


FUNCTION 


jDEVICE REQUIREMENTS 


|SYSLIN 

I 
I 


f- 

jSYSLIB 

Y - 

jSYSUTl 


Primary input data, normally the output 
of the compiler 


|"direct-access 
(•magnetic tape 
|•card reader 


automatic call library (SYSl.FORTLIB) 
work data set 
diagnostic messages 


j "direct-access 

"+- 

|•direct-access 


h 

| SYSPRINT 

I 


|sprinter 
(•magnetic tape 
|•direct-access 


| SYSLMOD 


i-- 

|user-specified 


output data set for the load module 
additional libraries and object modules 


j•direct-access 

- i- 

|•direct-access 
|"magnetic tape 

_i_ 
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(Additional inputs are partitioned data 
sets or sequential data sets,) The ddname 
for the DD statement that identifies any 
additional libraries is written in INCLUDE 
and LIBRARY statements and is not fixed by 
the linkage editor. 

The device classes used by the compiler 
(see Table 3) mu£t also be used with the 
linkage editor. The data sets used by 
linkage editor may be assigned to the 
device classes listed in Table 6. 


Table 6. Correspondence Between Linkage 
Editor ddnames and Device Class¬ 
es and Device Classes 


r 

| ddname 

T 

|Possible Device Classes 

|_ 

|SYSLIN 

1 

1 

1 

1 

1 

T 

|SYSSQ,SYSDA, or the input 
jstream device (specified 
j by DD * or DD DATA) or 
jdevice specified as the 
j card reader 

I 

r 

|SYSLIB 

i _ 

T 

|SYSDA 

i 

i 

jSYSUTl 

I 

|SYSDA 

I 

r 

j SYSLMOD 

1 

j SYSDA 

1 . 

r 

|SYSPRINT 

L 

T 

|A,SYSSQ 

_L 

r t 

| user-specified|SYSDA,SYSSQ 


Additional Input 

The INCLUDE and LIBRARY statements are 
used to specify additional secondary input 
to the linkage editor. Modules neither 
specified by INCLUDE or LIBRARY statements 
nor contained in the primary input are 
retrieved from the automatic call library. 


INCLUDE Statement: 


r- t- 

| Operation|Operand 

(. - + - 

|INCLUDE |ddname ((member-name 

j [,member-name]...)] 

I j [,ddname((member-name 

j [,member-name]...)]]... 
l_ ± - 


The INCLUDE statement is used to include 
either members of additional libraries 
(PDS) or a sequential data set. The 
"ddname" specifies a DD statement that 
defines either a PDS containing object 
modules and control statements or just load 
modules, or defines a sequential data set 
containing object modules and control 


statements. The "member name" is the name 
of a member of a PDS and is not used when a 
sequential data set is specified. 

The linkage editor inserts the object 
module or load module in the output load 
module when the INCLUDE statement is 
encountered. 


LIBRARY Statement: 

r - T -T 

|Operation|Operand 

j.-1-_| 

|LIBRARY |ddname (member-name | 

j j [,member-name]...) | 

| j [,ddname(member-name | 

j j [,member-name]...)]... | 

l -j.-J 


The LIBRARY statement is used to include 
members of additional libraries. The 
"ddname" must be the name of a DD statement 
that specifies a PDS that contains either 
object modules and linkage editor control 
statements, or just load modules. The 
"member name" is an external reference that 
is unresolved after primary input process¬ 
ing is complete. 

The LIBRARY statement differs from the 
INCLUDE statement in that external referen¬ 
ces specified in the LIBRARY statement are 
not resolved until all other processing, 
other than those references reserved for 
the automatic call library, are completed 
by the linkage editor. (INCLUDE statements 
resolve external references when the 
INCLUDE statement is encountered.) 

Example: Two subprograms, SUB1 and SUB2, 

and a main program, MAIN, are compiled by 
separate job steps. In addition to the 
FORTRAN library, a private library, MYLIB, 
is used to resolve external references to 
the symbols X, Y, and Z. Each of the 
object modules is placed in a sequential 
data set by the compiler, and passed to the 
linkage editor job step. 

^ Figure 26 shows the control statements 

for this job. ( Note; Cataloged procedures 
are not used.) In this job, an additional 
library, MYLIB, is specified by the LIBRARY 
statement and the ADDLIB DD statement. 
SUBl and SUB2 are included in the load 
module by the INCLUDE statements and the DD 
statements DDl and DD2. The linkage editor 
input stream, SYSLIN, is two concatenated 
data sets: the first data set is the 
sequential data set &GOFILE which contains 
the main program; the second data set is 
the two INCLUDE statements and the LIBRARY 
statement. After linkage editor execution, 
the load module is placed in the PDS 
PROGLIB and given the name CALC. 
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Linkage Editor Priority 

If modules with the same name appear in 
the input to the linkage editor, only one 
of the modules is inserted in the output 
load module. The following priority for 
modules is established by the linkage edi¬ 
tor : 

1. Modules appearing in SYSLIN or modules 
identified by INCLUDE statements. 

2. Modules identified by the LIBRARY 
statement. 

3. Modules appearing in SYSLIB. 

For example, if a module named SIN 
appears both in a module identified in a 
LIBRARY statement and in the automatic call 
library, only the module identified in the 
LIBRARY statement is inserted in the output 
load module. 


If modules with the same name appear in 
a single data set, only the module encoun¬ 
tered first is inserted in the output load 
module. 


Multiple Link Editing Within a Step 

Just as the compiler can perform several 
compilations within a procedure step or job 
step (batched compilation), the linkage 
editor can produce several load modules 
within a single procedure step or job step. 
Another linkage editor control statement, 
the NAME statement, is used to delimit the 
input for one load module from the input 
for another load module. 

r- t- 1 

|Operation|Operand | 

Y -+- 1 

|NAME |member-name((R)] 

L_ X _J 


//JOBX 
//STEP1 


JOB 

EXEC 


PGM=IEYFORT,PARM= * NAME=MAIN,LOAD* 


//SYSLIN DD 
//SYSIN DD 


D SNAME= 6 GOFILE,DISP=(,PASS) ,UNIT=SYSSQ 

♦ 

Source module for MAIN 


/* 

//STEP2 EXEC 


PGM=IEYFORT,PARM='NAME=SUB1,LOAD 1 


//SYSLIN DD 
//SYSIN DD 


DSNAME=SSUBPROGl,DISP=(,PASS),UNIT=SYSSQ 

* 

Source module for SUB1 


/* 

//STEP3 EXEC 


PGM=IEYFORT,PARM='NAME=SUB2,LOAD' 


//SYSLIN DD 
//SYSIN DD 


DSNAME=£SUBPROG2,DISP=(,PASS),UNIT=SYSSQ 

* 

Source module for SUB2 


/* 

//STEP4 EXEC 


//SYSLIB 

//SYSLMOD 

//ADDLIB 

//DDl 

//DD2 

//SYSLIN 

// 


/* 


DD 

DD 

DD 

DD 

DD 

DD 

DD 

INCLUDE 

INCLUDE 

LIBRARY 


PGM=IEWL 


DSNAME=SYSl.FORTLIB,DISP=OLD 
DSNAME=PROGLIB(CALC),UNIT=SYSDA 
DSNAME=MYLIB,DISP=OLD 
DSNAME=*.STEP2.SYSLIN,DISP=OLD 
DSNAME=*.STEP3.SYSLIN,DISP=OLD 
DSNAME=*.STEP1.SYSLIN,DISP=OLD 
* 

DDl 

DD2 

ADDLIB(X,Y,Z) 


Figure 26. Linkage Editor Example 
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The NAME statement is placed after the 
last object module or linkage editor con¬ 
trol statement used as input to a load 
module. Any modules or control statements 
following a NAME statement are assumed to 
be part of the next load module being 
constructed, A NAME statement can be 
placed only in the primary input: any NAME 
statements iri the secondary input are 
ignored. 


All of the resulting load modules from a 
batched linkage editor execution are placed 
in the library (PDS) specified in the 
SYSLMOD DD statement. The member name for 
each of the resulting load modules is 
specified as "member name" in the NAME 
statement. For example, if the primary 
input for one of the load modules is 
followed by a NAME statement containing the 
member name XALPHA, and the SYSLMOD DD 
statement for the linkage editor step spec¬ 
ifies the PDS MYLIB, the resulting load 
module is assigned the member name XALPHA 
and is placed in the PDS MYLIB. The 
SYSLMOD DD statement should not contain a 
member name. However, if the SYSLMOD 
statement contains a member name, that 
member name must be identical to the member 
name specified in the first NAME statement 
appearing in the primary input. 

The NAME statement can be used to speci¬ 
fy that a load module currently residing in 
a PDS is to be replaced by the load module 
constructed from the input immediately 
preceding the NAME statement. Replacement 
is specified by coding (R) following the 
member name in the NAME statement. 

When several load modules are. created in 
a single step (multiple link editing), the 
options specified in the EXEC statement for 
that step apply to each load module created 
in that step. 


Example: An object module resides on a 
sequential data set PROGX. A load module 
is to be constructed from this module, 
using the FORTRAN library and a private 
library MYLIB to resolve external referen¬ 
ces within the module. Another object 
module resides on a sequential data set 
PROGY, and a load module is to be con¬ 
structed from this object module using the 
same library to resolve external referen¬ 
ces. Both load modules are to be placed in 
the library PROGLIB. The first module is 
to be assigned the member name FUNTST; the 
second module is assigned the member name 
SUBTST. 

The following text shows the job control 
statements and the position of INCLUDE, 
LIBRARY, and NAME linkage editor statements 
necessary to perform the job. 


//JOB2 JOB 108,'J.JONES' 

//STEP EXEC PGM=IEWL 

//SYSLIB DD DSNAME=SYS1.FORTLIB,DISP=OLD 
//SYSLMOD DD DSNAME=PROGLIB,DISP-OLD 


//DD1 DD DSNAME=PROGX,DISP=OLD 
//DD2 DD DSNAME=PROGU,DISP=OLD 
//ADDLIB DD DSNAME=MYLIB 
//SYSLIN DD * 

INCLUDE DD1 
LIBRARY ADDLIB(X,Z) 

NAME FUNTST 
INCLUDE DD2 
LIBRARY ADDLIB(Y,Z) 

NAME SUBTST 

/* 


The JOB statement JOB2 defines the job, 
and the EXEC statement STEP instructs the 
operating system to execute the program 
IEWL. The DD statement SYSLIB tells the 
linkage editor that the FORTRAN library is 
the automatic call library. The SYSLMOD DD 
statement tells the linkage editor that 
both modules are written in the PDS 
PROGLIB. 

The first INCLUDE statement and the DD 
statement DD1 tell the linkage editor that 
the first load module is to contain the 
object module that resides on the sequen¬ 
tial data set PROGX. The first LIBRARY 
statement tells linkage editor that the 
references to X and Z in this module are to 
be resolved by the library MYLIB. The 
first NAME statement tells the linkage 
editor that the resulting module is 
assigned the member name FUNTST. The con¬ 
trol statements are similar for the load 
module with the member name SUBTST. 


Other Linkage Editor Control Statements 

In addition to the LIBRARY and INCLUDE 
statements, other control statements are 
available for use with the linkage editor. 
These statements enable the user to: speci¬ 
fy different names for load modules 
(ALIAS), replace modules within a loaa 
module (REPLACE), change program names 
(CHANGE), and name entry points (ENTRY). 
In addition, two statements, OVERLAY and 
INSERT, enable the programmer to overlay 
load modules. For a detailed description 
of these control statements, see the Link¬ 
age Editor publication. 


Options for Linkage Editor Processing 

The linkage editor options are specified 
in an EXEC statement. The options that are 
most applicable to the FORTRAN programmer 
are: 
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fPARM i [MAP 1 

lPARM.procstepf=( [_XREFj [, LET] [ , NCAL] 

[,LIST]) 

Other options can also be specified for 
the linkage editor. For a detailed de¬ 
scription of all linkgae editor options, 
see the Linkage Editor publication. 


MAP or XREF; The MAP option informs the 
linkage editor to produce a map of the load 
module; this map indicates the relative 
location and length of main programs and 
subprograms. If XREF is specified, a nap 
of the load module is produced and a 
cross-reference list indicating all exter¬ 
nal references in each main program and 
subprogram is generated. The map and/or 
cross-reference list are written in the 
data set specified by the SYSPRINT DD 
statement. If neither option is specified, 
no map or cross-reference listing is gener¬ 
ated. Descriptions of the map and cross- 
reference listing are given in the section 
"System Output." 


LET: The LET option informs the linkage 
editor to mark the load module executable 
even though error conditions, which could 
cause execution to fail, have been 
detected. 


NCAL: The NCAL option informs the linkage 
editor that the libraries specified either 
in the SYSLIB DD statement or in LIBRARY 
statements are not used to resolve external 
references. (The SYSLIB DD statement need 
not be specified.) The subprograms in the 
libraries are not inserted in the load 
module; however, the load module is marked 
executable. 


LIST: The LIST option indicates that all 
linkage editor control statements are list¬ 
ed in card-image format in the data set 
specified by the SYSPRINT DD statement. 


LOAD MODULE EXECUTION 

The ddnames used in executing load 
modules must meet the format specified by 
IBM. When the system is generated, device 
names are assigned by the operating system 
and the installation; the programmer choos¬ 
es devices by specifying either the instal¬ 
lation or operating system names. 

Program Name 

When "PGM=program name" is used to indi¬ 
cate the execution of a load module, the 


module must be in either the system library 
(sysl .LINKLIB) or a private library. When 
the module is in a private library, a 
JOBLIB DD statement must be supplied to 
indicate the name of the private library. 
For example, assume that the load modules 
CALC and ALGBRA in the library MATH and the 
load module MATRIX in the library MATRICES 
are executed in the following job: 


//JOBN JOB 00,FORTPROG 

//JOBLIB DD DSNAME=MATH,DISP=(OLD,PASS) 
// DD DSNAME=MATRICES,DISP=(OLD,PASS) 
//STEP1 EXEC PGM=CALC 


//STEP2 EXEC PGM=MATRIX 


//STEP3 EXEC PGM=ALGBRA 


The JOBLIB DD statement concatenates the 
private library MATH with the system 
library. The private library MATRICES is 
concatenated with the system Horary by 
concatenating the second DD statement with 
the JOBLIB DD statement. 


Execution ddnames < 

In the source module, aata set reference 
numbers are used to identify data sets. 
Data sets processed by a FORTRAN load 
module must be defined by DD statements. 
The correspondence between a data set ref¬ 
erence number and a DD statement is made by 
a ddname. 


The ddname format that must be used for 
load module execution is 

FTxxFyyy 

where: 

xx is the data set reference number 
yyy is a FORTRAN sequence number 


Data Set Reference Number (xx): When the 
system is generated, the upper limit for 
data set reference numbers specified by the 
installation is 99. This upper limit does 
not correspond to the number of 
input/output devices. 

If an installation specifies an upper 
limit of 99 for its data set reference 
numbers, the ddnames and data set reference 
numbers correspond as shown in Table 7. 
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Table 7. Load Module ddnames 


Statements 


ddname 


r- T -1 

| Data Set Reference Numbers | ddnames | 

h-+-^ 

FTOlFyyy 


1 

2 


FT02Fyyy 


13 


FTl3Fyyy 


99 


FT99Fyyy 


L_X-J 


FORTRAN Sequence Number (yyy): The FORTRAN 
sequence number is used to refer to separ¬ 
ate data sets that are read or written 
using the same data set reference number. 
For the first data set, the sequence number 
is 001; for the second 002; etc. This 
sequence number is incremented when (1) an 
END FILE statement is executed and a subse¬ 
quent WRITE is issued with the same data 
set reference number or (2) the ”END=" exit 
is taken following a READ and a subsequent 
READ or WRITE is issued with the same data 
set reference number. 

A DD statement with the required ddname 
must be supplied every time the WRITE, END 
FILE, WRITE sequence occurs. If the FOR¬ 
TRAN statements in the following example 
are executed, DD statements with the 
ddnames indicated by the arrows must be 
supplied for the corresponding WRITE state¬ 
ments. 


15 FORMAT(3F10.3,17) 
10 FORMAT(3F10.3) 

DO 20 1=1,J 


20 WRITE (17,10)A,B,C-> FT17F001 


END FILE 17 
DO 30 1=1,N 


30 WRITE (17,15)X,Y,Z,K-> FT17F002 

END FILE 17 
DO 40 1=1,M,2 


40 WRITE (17,10)A,B,C-> FT17F003 


END FILE 17 


If the preceding instructions are used 
to write a tape, the output tape is unla¬ 
beled and has the appearance shown in 
Figure 27. 


tapemark tapemark tapemark 


records 

records 


records A 

r 1 

|A,B,C|A,B,C|...|A,B,C| 

L_X-X_X-X. 

r 

Ix,Y,Z,K|X»Y,Z,Kl...ix f Y,Z 

-J. J. JL X 

-T J 

fK| 

_X_ 

■ I 

T T T T T 

|A,B,C|...|A,B,C| |.. 

-X XX XX 

V J 

Written using DD 
statement FT17F001 

Written using DD 
statement FT17F002 


Written using DD 
statement FT17F003 


Figure 27. Tape Output for Several Data Sets Using Same Data Set Reference Number 
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Reference Numbers for Data Sets Specified 
in DEFINE FILE Statements 


The characteristics of any data set to 
be used during a direct-access input/output 
operation must be described by a DEFINE 
FILE statement. 


The data sfet reference number specified 
in any DEFINE FILE statement may refer to 
only one data set. In other words, the 
method described previously concerning ref¬ 
erences to separate data sets that are read 
or written using the same data set ref¬ 
erence number is prohibited. For example, 
the statement 


DEFINE FILE 2(50,100,L,12) 

establishes a data set reference number of 
02. All subsequent input/output statements 
must refer to only one data set with the 
FORTRAN sequence number of FT02F001. (For 
a more detailed explanation of the DEFINE 
FILE statement, refer to the FORTRAN IV 
Language publication.) 

Retrieving Data Sets Written with Varying 
FORTRAN Seguence Numbers 

To retrieve the data sets shown in 
Figure 27, the data set sequence number in 
the LABEL parameter must be supplied in the 
DD statement. The LABEL parameter is de¬ 
scribed in detail in the section "Creating 
Data Sets." 

/' NL l 

LABEL=( [data-set-sequence-number] SLj ) 

The "data set sequence number" indicates 
the position of the data set on a sequen¬ 
tial volume. (This sequence number is 
cataloged.) For the first data set on the 
volume, the data set sequence number is 1; 
for the second, it is 2; etc. 


If one of the data sets shown in Figure 
27 is read in the same job step in which it 
is written, an END FILE statement must be 
issued after the last WRITE instruction. 
If the data set is to be read by the same 
data set reference number, DD statement 
FT17F004 is used to read the data set. The 
execution of a READ statement following an 
END FILE increments the FORTRAN sequence 
number by 1. For example, the following DD 
statements are used to write the three data 
sets shown in Figure 27 and then read the 
second data set: 


//FT17F001 DD 
//FT17F002 DD 
// 

//FT17F003 DD 
// 

//FT17F004 DD 
// 


UNIT=TAPE,LABEL=(,NL) 
UNIT=TAPE,LABEL=(2,NL), 
VOLUME=REF=*.FT17F001 
UNIT=TAPE,LABEL=(3,NL), 
VOLUME=REF=*.FT17F001 
VOLUME=REF=*.FT17F002 
DISP=OLD,LABEL=(2,NL) 


X 

X 

X 


The VOLUME parameter indicates that the 
data set resides on the same volume as the 
data set defined by DD statement FT17F001. 
DD statement FT17F004 refers to the data 
set defined by DD statement FT17F002. 

If the data set is read by a different 
data set reference number, for example, 
data set reference number 18; then, the DD 
statement FT17F004 is replaced ny the 
statement: 

//FT18F001 DD VOLUME=REF=*.FT17F002, X 
// DISP=OLD,LABEL=(2,NL) 

If the data sets shown in Figure 27 are 
cataloged for the purpose of later reading 
them, and the following DD statements are 
used to write the data sets. 


//FT17F001 DD DSNAME=N1,LABEL=(1,NL), X 

// DISP=(,CATLG),UNIT=TAPE 

//FT17F002 DD DSNAME=N2,LABLL=(2,NL), X 

// VOLUME=REF=*.XT17F001, X 

// UNIT=TAPE,DISP=(,CATLG) 

//FT17F003 DD DSNAME=N3,LABEL=(3,NL), X 

// VOLUME=REF=*.FT17F002, X 

// UNIT=TAPE,DISP=( r CATLG) 


The information necessary to retrieve the 
data sets is the DSNAME, the LABEL, and the 
DISP parameters. For example, if data set 
reference number 10 is used to retrieve 
data set Nl, the following DD statement is 
required. 

//FT10F001 DD DSNAME=Nl,DISP=OLD, X 

// LABEL=(1,NL) 

If the data set is not cataloged and 
then retrieved in a later job, the VOLUME, 
UNIT, and LABEL information is needed to 
retrieve the data set. When the data set 
is created, the programmer must assign a 
specific volume to it. 

Assume the data sets shown in Figure 27 
were assigned the volume identified by the 
volume serial number Alllll when the data 
sets were created. If the second data set 
written on the volume is retrieved by data 
set reference number 10 in a later job, the 
following DD statement is needed. 

//FT10F001 DD VOLUME=SER=Alllll,DISP=OLD, X 
// LABEL=(2,NL),UNIT=SYSSQ 

END Exit: Data sets written using the same 
data set reference number can be retrieved 
in the same job or job step by using a 
facility provided in the FORTRAN language - 
the "END=" exit in a READ statement. 
After the last data set is written and the 
END FILE is executed, a REWIND is issued. 
A subsequent READ using the same data set 
reference number resets the FORTRAN 
sequence number to 001. When the last 
record of a data set has been read, an 
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additional READ causes the END exit to be 
taken. On the next READ, the sequence 
number is incremented by 1. The data sets 
shown in Figure 27 can be read by using the 
following sequence of statements. 

Note: The DD statements used to create the 
data sets also suffice for retrieving the 
data sets. No additional DD statements are 
required. 

REWIND 17 


100 READ(17,10,END= 200)A,B,C-> FT17F001 


GO TO 100 


200 READ(17 # 15 f END= 300)X,Y,Z,K->FT17F002 


GO TO 200 


300 READ(17,10,END= 350)A,B,C-> FT17F003 


GO TO 300 


350 


Concatenation: The data sets shown in 

Figure 27 can be concatenated and read as a 
single data set. The information necessary 
(assume cataloged data sets) to retrieve 
the data sets is the DSNAME, LABEL, and 
DISP parameters. For example, if data set 
reference number 16 is used to retrieve the 
data sets, the following DD statements are 
required. 

//FT16F001 DD DSNAME=N1,DISP=OLD, X 

LABEL=(1,N) 

// DD DSNAME=N2,DISP=OLD,LABEL=(2,NL) 

// DD DSNAME=N3,DISP=OLD,LABEL=(3,NL) 

Note: Concatenation of data sets defined 

by direct-access statements is not allowed. 


ERR=Parameter 

The ERR= parameter may be used to give 
control to the problem program if an uncor- 
rectable I/O error occurs on a magnetic 


tape or direct access device. This param¬ 
eter is not effective for data sets on unit 
record devices. 


REWIND and BACKSPACE Statements 

The REWIND and BACKSPACE statements 
force execution of positioning operations 
by the control program. 

A REWIND statement instructs the control 
program to position the volume on the 
device so that the next record reaa or 
written is the first record transmitted for 
that data set reference number on that 
volume, irrespective of data set sequence 
numbers. 

The effect of a BACKSPACE statement 
depends upon the record format and the type 
of control used to read or write the record 
(FORMAT control or no FORMAT control). For 
specific information concerning BACKSPACE, 
see "Backspace Operations" in the section 
"Creating Data Sets." 

Note: REWIND, BACKSPACE or END FILE state¬ 
ments specified for data sets defined in 
direct-access statements are ignored. 


Error Message Data Set 

When the system is generated, the 
installation assigns a data set reference 
number so that execution error messages can 
be written on a data set. The programmer 
must define a data set, using a DD state¬ 
ment with the ddname for that data set 
reference number. This data set should be 
defined using the SYSOUT=A parameter. 

If this data set is not defined and an 
error condition is encountered during the 
execution of the job step, the job step is 
terminated and a condition code of 16 is 
issued. 

Execution Device Classes 

For load module execution, the program¬ 
mer can use the same names assigned to 
device classes used by the compiler (shown 
in Table 3). However, additional names for 
specific devices and device classes can be 
assigned by the installation. The program¬ 
mer can choose which device to use for his 
data sets, and specify the name of the 
device or class of devices in the UNIT 
parameter of the DD statement. 

DCB Parameter 

The DCB parameter may be specified for 
data sets when a load module is executed. 
For information concerning the DCB paramet¬ 
er, see the section "Creating Data Sets." 
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CREATING DATA SETS 


Data sets are created by specifying 
parameters in the DD statement or by using 
a data set utility program. This section 
discusses the use of the DD statement to 
create data sets. (The Utilities publica¬ 
tion discusses data set utility programs.) 
No consideration is given to optimizing I/O 
operations; this information is given in 
the section "Programming Considerations." 

To create data sets, the DSNAME, UNIT, 
VOLUME, SPACE, LABEL, DISP, SYSOUT, and DCB 
parameters are of special significance (see 
Figure 28). These parameters specify: 


DSNAME - name of the data set 
UNIT - class and number of devices used 
for the data set 

VOLUME - volume on which the data set 
resides 

LABEL - label specification 
DISP - the disposition of the data set 

after the completion of the job 
step 

SYSOUT - ultimate device for unit record 
data sets 

DCB - tape density, record format, 

record length 

Examples of DD statements used to create 
data sets are 


USE OF DD STATEMENTS FOR DIRECT-ACCESS DATA 
SETS 

Data sets that are referred to in FOR¬ 
TRAN direct-access input/output statements 
must first be defined in the DEFINE FILE 
statement. However, the DD statement may 
be used in conjunction with the DEFINE FILE 
statement for designating other charac¬ 
teristics of the data set. 


If the user chooses to exercise this 
option, caution must be taken in specifying 
the parameters in the DD statement (Figure 
28). The following parameters may not be 
used with FORTRAN defined direct-access 
data sets because of the conflict in speci¬ 
fications: DUMMY, UNIT, and the DEN and 
TRTCH subparameters in the DCB parameter. 
The UNIT parameter may not specify the 
number of devices allotted to the data set. 
This restriction is placed on the UNIT 
parameter because the direct-access method 
used by the system supports only one 
device. The remaining parameters of the DD 
statement must conform to the specifi¬ 
cations in the DEFINE FILE statement. 


The following statements illustrate the 
possible conflicts that may arise between 
the DEFINE FILE and DC statements. 


DEFINE FILE 2(50,100,E,12) 

//FT02F001 DD DSNAME=BOOL,DISP= (NEW ,CATLG)1 
// LABEL=(,SL),UNIT=SYSDA, 2 
// VOLUME=(PRIVATE,RETAIN), 3 
// SPACE=(100,(30,50)),,CONTIG, 4 
// DCB=(DEN=1,RECFM=F,BLKSIZE=100) 


The SPACE parameter must be included for 
all direct-access data sets, but it must 
also conform to the DEFINE FILE statement; 
the record length in both statements must 
be the same. In the DCB parameter, the 
subparameter DEN applies only to aata sets 
residing on magnetic tape volumes. If the 
DUMMY parameter is specified in a DD state¬ 
ment for a direct-access data set, the 
conflict arises because the disposition of 
a direct-access data set is always checked 
and a dummy data set has no disposition. 

Note: The name field of the DD statement 
must contain FTxxFOOl; where xx is the data 
set reference number specified in the 
DEFINE FILE statement. 


DATA SET NAME 

The DSNAME parameter specifies the name 
of the data set. Only four forms of the 
DSNAME parameter are used to create data 
sets. 

|DSNAME=dsname | 

|DSNAME=dsname(element)J 

specify names for data sets that are 
created for permanent use. 

DSNAME=£name | 

DSNAME= Sname(element)) 

specify data sets that are temporarily 
created for the execution of a single 
job or job step. 

DUMMY 

is specified in the DD statement to 
inhibit I/O operations specified for 
the data set. A write statement is 
recognized, but no data is transmit¬ 
ted. (When the programmer specifies 
DUMMY in a DD statement used to over¬ 
ride a cataloged procedure, all param¬ 
eters in the cataloged DD statement 
are overridden.) 
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Figure 28. DD Parameters for Creating Data Sets 





Figure 29. Examples of DD Statements 


Note: A dummy data set should only be 
read if the "END=" option is specified 
in the FORTRAN READ statement. If the 
option is not specified, a read causes 
an end of data set condition and 
termination of execution of the load 
module. 


DDNAME=ddname 

indicates a dummy data set that will 
assume the characteristics specified 
in a following DD statement of 
"ddname." The DD statement identified 
by "ddname" then loses its identity; 
that is, it cannot be referred to by 
an *....ddname parameter. The state¬ 
ment in which the DDNAME parameter 
appears may be referenced by subse¬ 
quent *....ddname parameters. If a 
subsequent statement identified by 
"ddname" does not appear, the data set 
defined by the DD statement containing 
the DDNAME parameter is assumed to be 
an unused statement. The DDNAME 
parameter can be used five times in 
any given job step or procedure step. 


but no two uses can refer to the same 
"ddname." The DDNAME parameter is 
used mainly for cataloged procedures. 


SPECIFYING I/O DEVICES 

The programmer specifies the name and 
number of I/O devices in the UNIT parame¬ 
ter : 

UNIT=(name[,Cn|P>]) 
name 

is given to the input/output device 
when the system is generated. 

n j P 

specifies the number of devices allo¬ 
cated to the data set. 


SPECIFYING VOLUMES 

The programmer indicates the volumes 
used for the data set in the VOLUME parame¬ 
ter: 



VOLUME=([PRIVATE] [,RETAIN] 

[,volume-sequence-number] 
[, volume-count] 


* SER=(volume-serial-number 

[,volume-serial-number]-..) 

I dsriaroe \ 

♦.ddname I ) 

*.step.ddname j 

*.stepname.procstep.ddname ) 


identifies the volume(s) assigned to 
the data set. 


SER 

specifies one or more ferial numbers 
for the volumes required by the data 
sets. A volume serial number consists 
of one to six alphameric characters. 
If it contains less than six charac¬ 
ters, the serial number is left 
adjusted and padded with blanks. If 
SER is not specified, and DISP is not 
specified as NEW, the data set is 
assumed to be cataloged and serial 
numbers are retrieved from the cata¬ 
log, or inherited from passed data 
sets in a previous step. A volume 
serial number is not required for new 
output data sets. 


PRIVATE 

is used only for direct-access 
volumes. This subparameter indicates 
that the assigned volume is to contain 
only the data set defined by this DD 
statement. PRIVATE is overridden when 
the DD statement for a data set 
requests the use of the private volume 
with the SER or REF subparameter. 
Volumes other than direct-access 
access volumes are always considered 
PRIVATE. 


RETAIN 

indicates that this volume is to 
remain mounted after the job step is 
completed. Volumes are retained so 
that data may be transmitted to or 
from the data set, or so that other 
data sets may reside on the volume. 
If the data set requires more than one 
volume, only the last volume is 
retained; the other volumes are dis¬ 
mounted when the end of volume is 
reached. Another job step indicates 
when to dismount the volume by omit¬ 
ting RETAIN. If each job step issues 
a RETAIN for the volume, the retained 
status lapses when execution of the 
job is completed. 


volume-sequence-number 

is a one-to-four digit decimal number 
that specifies the sequence number of 
the first volume of the data set that 
is read or written. The volume 
sequence number is meaningful only if 
the data set is cataloged and volumes 
lower in sequence are omitted. 


volume-count 

specifies the number of volumes 
required by the data set. Unless the 
SER or REF subparameter is used, this 
subparameter is required for every 
multi-volume output data set. 


REF 

indicates that the data set is to 
occupy the same volume(s) as the data 
set identified by "dsname", 
"♦.ddname", " ♦ , stepnan.e . daname" , or 
♦.stepname.procstep.ddname. Table 8 
shows the data set references. 


When the data set resides on a tape volume 
and REF is specified, the data set is 
placed on the same volume, immediately 
behind the data set referred to by this 
subparameter. When this suoparameter is 
used, the UNIT parameter must be omitted. 


Table 8. Data Set References 


r ~ 

i 


h 


Option 


Refers to 


h 


REF=dsname 


a data set named 
"dsnan e" 


H 


REF=*.ddname 


h 


a data set indica¬ 
ted by DD statement 
"ddname" in the 
current job step 


H 


REF=*.stepname.ddname 


a data set indica¬ 
ted by DD statement 
"ddname" in the job 
step "stepname" 


H 


REF=*.stepname. 

procstep.ddname 


a data set indica¬ 
ted by DD statement 
"ddname" in the 
procedure step 
"procstep" invoked 
in the job step 
"stepname" 


If SER or REF is not specified, the 
control program will allocate any non¬ 
private volume that is available. 
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SPECIFYING SPACE ON DIRECT-ACCESS VOLUMES 

I TRK ) 

CYL \ 

average-record-length I 

,(primary-quantity 

[,secoridary-quantity] 

[,directory-quantity]) 


The SPACE parameter specifies: 

1. Units of measurement in which space is 
allocated. 

2. Amount of space allocated. 

3. Whether unused space can be released. 

4. In what format space is allocated. 


20 cylinders are allocated to the data 
set. When previously allocated space 
is exhausted, two additional cylinders 
are allocated. In addition, space is 
reserved for five 256-byte blocks in 
the directory of a PDS. 


RLSE 


indicates that all unused external 
storage assigned to this data set is 
released when processing of the data 



, MXIG 


[,RLSE] 

,ALX [,ROUND]) 

MXIG 


,CONTIG 

ALX 


L. 

CONTIG 


specify the format of the space allo¬ 
cated to the data set, as requested in 
the "primary quantity." 


MXIG 


requests the largest single block of 
contiguous storage that is greater 
than or equal to the space requested 
in the "primary quantity." 


{ TRK ) 

CYL 

average-record-length] 

specifies the units of measurement in 
which storage is assigned. The units 
may be tracks (TRK), cylinders (CYL), 
or records (average record length (in 
bytes) expressed as a decimal number 
<65,535). 


ALX 

requests all available storage on the 
volume as long as there is at least as 
much space as specified in the 
"primary quantity." The operating 
system must be able to allocate at 
least the amount specified as the 
"primary quantity" by using, at most, 
five non-contiguous areas of storage. 


(primary-quantity[,secondary-quantity] 

[,directory-quantity]) 

specifies the amount of space 
allocated for the data set- The 
"primary quantity" indicates the num¬ 
ber of records, tracks, or cylinders 
to be allocated when the job step 
begins. The "secondary quantity" 
indicates how much space is to be 
allocated each time previously allo¬ 
cated space is exhausted. ( Note: The 
maximum number of times secondary 
allocation will be made is 15.) 

The "directory quantity" is used only 
when writing a PDS, and it specifies 
the number of 256-byte blocks to re¬ 
serve for the directory of the PDS. 

For example, in the DD statement: 


CONTIG 

requests that the space indicated in 
the "primary quantity" be contiguous. 

If the subparameter is not specified, 
or if any option cannot be fulfilled, 
the operating system attempts to 
assign contiguous space. If there is 
not enough contiguous space, up to 
five non-contiguous areas are allocat-. 
ed. 

ROUND 

indicates that allocation of space for 
the specified number of records is to 
begin and end on a cylinder boundary. 

Note: If a data set might be written on a 
direct-access volume, the SPACE parameter 
must be specified in the DD statement. 


//FT10F001 DD SPACE=(120,(400,100)) 

space is reserved for 400 records, the 
average record length is 120 charac¬ 
ters. Each time space is exhausted, 
space for 100 additional records is 
allocated. 

In the statement: 

//FT22F001 DD SPACE=(CYL, (20,2,5)) 


LABEL INFORMATION 


The label parameter (LABEL) is used to 
specify the type and contents of a data set 
label. 


LABEL=([data-set-sequence-number] 


,NL 
, SL 


,EXPDT=yyddd 
,RETPD=xxxx ) 
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data-set-sequence-number 

is a four-digit number that identifies 
the relative location of the data set 
with respect to the first data set on 
a tape volume. (For example, if there 
are three data sets on a magnetic tape 
volume, the third data set is iden¬ 
tified by data set sequence number 3.) 
If the data set sequence number is not 
specified, the operating system 
assumes 1. 



specifies whether a data set is 
labeled or unlabeled. SL indicates 
standard labels. NL indicates no 
labels (applicable only to data sets 
residing on a tape volume)- 


DCB PARAMETER 

For load module execution, the FORTRAN 
programmer may specify record formats and 
record lengths for sequentially organized 
data sets that reside on magnetic tape or 
direct-access volumes. The DCB information 
is placed in the labels for these data 
sets. 


DCB= ( 


dsname 
*.ddname 

*.stepname.ddname 
_*.stepname.procstep.ddname 


[,DEN={0|1| 2}] (,TRTCH={C|E|T|ET}] 

I {F|U>[A][,BLKSIZE=xxxx] 

V[A],LRECL=xxxx,BLKSIZE=xxxx 

{F|V}B[A],LRECL=xxxx,BLKSIZE=xxxx 


[expdt= 


=yyddd 

=xxxx 


[RETPD= 

specifies how long the data set shall 
exist. The expiration date, 
EXPDT=yyddd, indicates the year (yy) 
and the day (ddd) the data set can be 
deleted. The period of retention, 
RETPD=xxxx, indicates the period of 
time, in days, that the data set is to 
be retained. If neither is specified, 
the retention period is assumed to be 
zero. 


DISPOSITION OF A DATA SET 

The disposition of a data set is speci¬ 
fied by the DISP parameter? see "Data 
Definition (DD) Statement." The same 
options are used for both creating data 
sets and retrieving previously created data 
sets. When a data set is created, the 
subparameters used are NEW, MOD, KEEP, 
PASS, and CATLG. 


[ ,BUFNO={l|2}]) 


REFERRING TO PREVIOUSLY SPECIFIED DCB 
INFORMATION 

The first subparameter 


dsname 
*.ddname 

*.stepname.ddname 
*.stepname.procstep.ddnamej 

is used to retrieve DCB parameter 
information from previously created 
data sets. The control program copies 
the DCB information specified for the 
data set referred to by this subparam¬ 
eter. The copied information is used 
for processing the data set defined by 
the DD statement in which the sub¬ 
parameter appears. Any subpararneters 
that follow this subparameter override 
any copied DCB subpararneters. 


WRITING A UNIT RECORD DATA SET ON AN 
INTERMEDIATE DEVICE 

A printed output data set may be written 
on an intermediate device and subsequently 
written on the printer (ultimate device). 

SYSOUT=A 

indicates that the ultimate destina¬ 
tion for printed output data sets is 
the printer. 

Note: If the DEN subparameter is explicit¬ 
ly specified for SYSOUT data sets, only 
DEN=2 is allowed in the DCB parameter. In 
addition, TRTCH=C must be specified in the 
DCB parameter when the SYSOUT data set (1) 
is written on 7-track tape, and (2) is 
composed of variable-length records or con¬ 
tains binary information. 


dsname 

indicates that the DCB subparameters 
of a cataloged data set "dsname” are 
copied. The data set indicated by 
"dsname" must be currently mounted and 
it must reside on a direct-access 
volume. 


*.ddname 

indicates that the DCB subparameters 
in a preceding DD statement "ddname" 
in the current job step are copied. 


*.stepname.ddname 

indicates that the DCB subparameters 
in a DD statement "ddname" that occurs 
in a previous job step "stepname" in 
the current job are copied. 
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*.stepname.procstep.ddname 

indicates that the DCB subparameters 
in the DD statement "ddname” are 
copied from a previous step "procstep" 
in a cataloged procedure. The proce¬ 
dure was invoked by the EXEC statement 
"stepname" in the current job. 


DENSITY AND CONVERSION 

The second subparameter indicates the 
density and conversion for tape volumes. 

DENSITY: Density is only specified for 

data sets residing on magnetic tape 
volumes. 

DEN={0|1|2} 

indicates the density used to write 
the data set (refer to Table 9). 

Table 9. DEN Subparameter Values 


r 

j DEN 

"T 

|Tape Recording 

L 

Density (bits/inch) 

1 

i 

1 

r 

i 

i 

Model 

2400 

(Value 

1 

r 

| 7-Track 
j 

T 

1 

l 

9-Track 

r 

1 0 

1 

I 200 

j 

T 

1 

1 

- 

r 

i i 

i 

j 556 

T 

1 

| 

- 

r 

1 2 

L 

1 

| 800 
_JL 

T 

1 

j.. 

800 


CONVERSION: Conversion is used only for 

data sets residing on 7-track tape volumes. 

TRTC H={C|E|T|ET} 

indicates which conversion type is 

used: 

C - data conversion feature is used 

E - even parity is used 

T - translation from either BCD to 
EBCDIC or EBCDIC to BCD is 
required 

ET - even parity is used and transla¬ 
tion from either BCD to EBCDIC or 
EBCDIC to BCD is required 


RECORD FORMAT 

[recfm=u[a] 

RECFM=V[B][A] 

[RECFM==F[B] [a]J 

The characters U, V, F, and B represent 

U - undefined records (records that do 
not conform to either the fixed- 
length or variable-length format) 


V - variable-length records (records 
whose length can vary throughout the 
data set) 

F - fixed-length records (records whose 
length is constant throughout the 
data set) 

B - blocked records 

The character A indicates the use of the 
extended ASA carriage control characters. 
(See Appendix E.) 


RECORD LENGTH, BUFFER LENGTH, BLOCK LENGTH, 
AND NUMBER OF BUFFERS FOR SEQUENTIAL DATA 
SETS 

For blocked records used by the compiler 
or linkage editor, the length of a block is 
specified by the buffer length which is 
specified by 

BLKSIZE=xxxx 

The record length (LRECL) is permanently 
specified by the compiler or linkage 
editor. 

For unblocked records used by the com¬ 
piler or linkage editor, the values for 
BLKSIZE and LRECL are permanently speci¬ 
fied. 

For unblocked fixed-length records or 
undefined records used during load module 
execution, the record length and the buffer 
length are specified by 

BLKSIZE=xxxx 

For unblocked variable-length records, 
the record length is specified by 

LRECL=xxxx 

buffer length is specified by 
BLKSIZE=xxxx 

For blocked variable-length or fixed- 
length records used by load modules, the 
record length is specified by 

LRECL=xxxx 

block length and buffer length are 
specified by 

BLKSIZE=xxxx 

Undefined records cannot be blocked. 

Table 10 is a summary of the specifi¬ 
cations made by the programmer for record 
types and blocking in FORTRAN processing. 
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Table 10. Specifications Made by the FORTRAN Programmer for Record Types and Blocking 


Step 


Blocked or 
Unblocked 


Record Type 


j RECFM | | 

jSpecification |Record Length jBuffer Length 


Compiler or 

Linkage 

Editor 


Unblocked 


h- 


Fixed-Length jnot specified 1 |not specified 1 jnot specified 1 


Blocked 


Fixed-Length jnot specified 1 |not specified 1 |BLKSIZE=xxxx 


Unblocked 


Load Module 
Execution 


Blocked 


Fixed-Length |RECFM=F 2 

-+- 

Variable-Length|RECFM=V 

-i- 

Undefined |RECFM=U 

-1- 

Fixed-Length |RECFM=FB 

-+- 

Variable-Length|RECFM=VB 


|BLKSIZE=xxxx 2 | 

-+-H 

|LRECL=xxxx | 

-+-H 

|BLKSIZE=xxxx |BLKSIZE=xxxx 

_ + -^ 

I I 

--| LRECL=xxxx 

i i 


Undefined 


|Blocked undefined records are not permitted 
-X_ 


Permanently specified by the compiler and cannot be altered. 
2 Not specified for direct access data sets. 


The number of buffers required to read Example; Assume BLKSIZE=44 
or write any data set is specified by 

10 FORMAT(F10.5,16,2F12.5,'SUMS') 

BUFNO=x WRITE(2 0,10)AB,NA,AC , AD 


Where: x=l or 2 


FORTRAN Records and Logical Records for 
Sequential Data Sets 

In FORTRAN, records for sequential data 
sets are defined by specifications in FOR¬ 
MAT statements and by READ/WRITE lists. A 
record defined by a specification in a 
FORMAT statement is a FORTRAN record (see 
the section "Input/Output Statements” in 
the FORTRAN IV Language publication). A 
record defined by a READ/WRITE list is a 
logical record . Within each category, 
there are three types of records: fixed- 
length, variable-length, and undefined. In 
addition, fixed-length and variable-length 
records can be blocked. 


UNBLOCKED RECORDS, FORMAT CONTROL: For 
fixed-length and undefined records, the 
record length and buffer length are 
specified in the BLKSIZE subparameter. For 
variable-length records, the record length 
is specified in the LRECL subparameter; the 
buffer length in the BLKSIZE subparameter. 
The information coded in a FORMAT statement 
indicates the FORTRAN record length (in 
bytes). 


|-BLKSIZE--j 

' 

-FORTRAN Record-1 


44 Bytes of Data 


Figure 30. FORTRAN Record (FORMAT Control) 
Fixed-Length Specification 

If the FORTRAN record length is less 
than BLKSIZE, the record is padded with 
blanks to fill the remainder of the buffer 
(see Figure 31). The entire buffer is 
written. 


Example: Assume BLKSIZE=56 

5 FORMAT (F10.5,I6,F12.5,'TOTAL*) 
WRITE (15,5) BC,NB,BD 


r 


BLKSIZE 


Written Record 


-FORTRAN Record- 


n 

i 

i 


33 Bytes of Data 


23 Bytes of Blanks 


Fixed-Length Records: For unblocked fixed- 
length records written under FORMAT 
control, the FORTRAN record length must not 
exceed BLKSIZE (see Figure 30). 


Figure 31. FORTRAN Record (FORMAT Control) 
With Fixed-Length Specification 
and FORTRAN Record Length Less 
Than BLKSIZE 
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Variable-Length Records: For unblocked 
variable-length records written under FOR¬ 
MAT control, LRECL is specified as four 
greater than the maximum FORTRAN record 
length; and BLKSIZE must be four greater 
than LRECL. The eight bytes are required 
for two prefix control fields (see Figure 
32). The first four-byte field (LL) con¬ 
tains system control information; the sec¬ 
ond four-byte field (11) contains the count 
of the number of data bytes. 


r ‘ 


BLKSIZE - 


r~ 


-LRECL - 


-FORTRAN Record 


LL 


Data 


Figure 32. FORTRAN Record (FORMAT Control) 
Variable-Length Specification 

If. the FORTRAN record length is less 
than (LRECL-4), the unused portion of the 
buffer is not written (see Figure 33). 


BLKSIZE 


Written Record--■ 



i 

i 

-LRECL-1 

1 

-FORTRAN Record- 

_l 

1 

1 

1 

1 

1 

| | 


1 T 

LL 

11 

Data 

Not Written 

L_J 

LU 


L "_J 


Figure 33. FORTRAN Record (FORMAT Control) 
With Variable-Length Specifi¬ 
cation and the FORTRAN Record 
Length Less Than (LRECL-4) 


Undefined Records; For undefined records 
written under FORMAT control, BLKSIZE is 
specified as the maximum FORTRAN record 
length. If the FORTRAN record length is 
less than BLKSIZE, the unused portion of 
the buffer is not written (see Figure 34). 


BLOCKED RECORDS, FORMAT CONTROL: For all 
blocked records, the record length is spec¬ 
ified in the LRECL subparameter; the block 
length and buffer length in the BLKSIZE 
subparameter. 


Fixed-Length Records: For blocked fixed- 

length records written under FORMAT 
control, LRECL is specified as maximum 
possible FORTRAN record length, and BLKSIZE 
must be an integral multiple of LRECL. If 
the FORTRAN record length Is less than 
LRECL, the rightmost portion of the record 
is padded with blanks (see Figure 35). 

Example: Assume BLKSIZE=48 and LRECL=24 

10 FORMAT(18,FI6.4) 

20 FORMAT(112) 


WRITE(13,1G)N,B 


WRITE(13,20)K 


- BLKSIZE- 

-Written Block — 


I-LRECL-r--LRECL-j 

' FORTRAN 

|-FORTRAN Record-L _ ^ 

I III 



12 

12 Bytes 

24 Data Bytes 

Data Bytes 

of 


Blanks 


Figure 35. Fixed-Length Blocked Records 
Written Under FORMAT Control 


Variable-Length Records: For blocked 
variable-length records written under FOR¬ 
MAT control, LRECL is specified as four 
greater than the maximum FORTRAN record 
length, and BLKSIZE must be 4 plus an 
integral multiple of LRECL. The four addi¬ 
tional bytes allocated with BLKSIZE are 
required for the control field (LL) that 
contains the block length. The four addi¬ 
tional bytes allocated with LRECL are used 
for the record-length indicator (11). 


1 I 

I l 

1 1 

I 1 

i_1__ 

BLKSIZE 

FORTRAN Record- 

1 

* — 






Data 

Not Written 





. _J 


Figure 34. FORTRAN Record (FORMAT Control) 
With Undefined Specification 
and the FORTRAN Record Length 
Less Than BLKSIZE 


If a WRITE is executed and the amount of 
space remaining in the present buffer is 
less than LRECL, only the filled portion of 
this buffer is written (see Figure 36); the 
new data goes into the next buffer. Howev¬ 
er, if the space remaining in a buffer is 
greater than LRECL, the buffer is not 
written, but held for the next WRITE (see 
Figure 36). If another WRITE is not exe¬ 
cuted before the job step is terminated, 
then the filled portion of the buffer is 
written. 
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Example: Assume BLKSIZE=28 and LRECL=12 

30 FORMAT(13,F5.2) 

40 FORMAT(F4.1) 

50 FORMAT(F7. 3 ) 


WRITE(12,30)M,Z 


WRITE(12,40)V 


WRITE(12,50)Y 



I-FORTRAN Record-, 


LL 

II 

7 Data Bytes 

This space of 13 bytes 

Ready for next WRITE . 


. 


(space > LRECL) 


Figure 36, Variable-Length Blocked Records 
Written Under FORMAT Control 

UNBLOCKED RECORDS, NO FORMAT CONTROL: The 
logical record length and the buffer length 
for fixed-length and undefined records are 
specified in the BLKSIZE subparameter. For 
variable-length records, the record length 
is specified in the LRECL subparameter; the 
buffer length in the BLKSIZE subparameter. 
The logical record length (in bytes) is 
controlled by the type and number of varia¬ 
bles in a READ/WRITE list. If the logical 
record length is less than or equal to the 
available space in a buffer, one logical 
record is written each time the buffer is 
written. However, if the logical record 
length exceeds the available buffer space, 
the logical record spans buffers. Each 
time a buffer is written, a record segment 
is written (a logical record can consist of 
one or more record segments). 

All record segments written without FOR¬ 
MAT control have a 4-byte prefix control 
field that contains the FORTRAN control 
word. This control word is made up of a 
record indicator (one byte) and, in the 
remaining three bytes, a count of the 
number of data bytes in the record segment. 


If a logical record does not span buffers, 
the record indicator is a 1. However, if 
the logical record consists of two or more 
record segments, the record indicator is a 
0 in all but the last segment. In this 
last segment, the indicator is set to the 
number of record segments in the logical 
record. 


Fixed-Length Records: For unblocked fixed- 
length records written without FORMAT 
control, the maximum length of a record 
segment is (BLKSIZE-4); however, the logi¬ 
cal record length may exceed BLKSIZE (see 
Figure 37). In addition, if the logical 
record length is less than (BLKSIZE-4), the 
rightmost portion of the record is padded 
with zeros (see Figure 37). 

Example: Assume BLKSIZE=16 

WRITE(17)A,B,C 

Where: A and B are double precision varia¬ 

bles . 

C is a real variable. 

\ -BLKSIZE-1 

I I 

I — — — — Record Segment — — — — —I 

i ' i 


FC 

0 

12 Data Bytes 

Record Segment ^ + Record Segment ^ = 1 Logical Record 

Record Segment ^ —j 

_1 

FC 

2 

8 Data Bytes 

4 Bytes 
of 

Zeros 


Figure 37. Logical Record Fixed-Length 
Specification 


Variable-Length Records: For unblocked 

variable-length records written without 

FORMAT control, the maximum length of a 
record segment (including 4 bytes for the 

prefix control field) is (LRECL-4). 

BLKSIZE must be 4 greater than LRECL. In 
summary, the 12 bytes not used for data and 
allocated for BLKSIZE are used for the 
three prefix control fields - LL, 11, and 
FC t (see Figure 38). The logical record 
length can exceed LRECL; however, if the 
length of the logical record or any record 
segment is less than (LRECL-4), the unused 
portion of the buffer is not written (see 
Figure 38). 

Example: Assume BLKSIZE=28 and LRECL=24 
10 WRITE(18)Q,R,V,X 

Where: Q and R are double precision varia¬ 

bles . 

V and X are real variables. 
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r~ 

i 



Record Segment ^ 

*1 

i 

r - 

i 



- BLKSIZE - 

— 1 

i 

i 

i 

— 

1 

— 

- LRECL - 

-1 

LL 

II 

FC 

0 

16 Data Bytes 


Record Segment ^ + Record Segment ^ = 1 Logical Record 

i- 

1 


— 

- Record Segment 0 -| 


LL 

II 

FC 

2 

8 Data Bytes 

n 

8 Bytes 

Not Written 


Figure 38. Logical Record Variable-Length 
Specification 

Undefined Records; For undefined records 
written without FORMAT control, the maximum 
length of a record segment (including the 
FORTRAN prefix control field) is BLKSIZE; 
however, the logical record length can 
exceed BLKSIZE (see Figure 39). In addi¬ 
tion, if the data length of a logical 
record or any record segment is less than 
(BLKSIZE-4), the unused portion of the 
buffer is not written (see Figure 39). 


BLKSIZE-1 


- ■ 

1 


"1 

_1 

FC 

0 

Data 


Record Segment ^ + Record Segment 2 = 1 Logical Record 

i- 

1 

Record Segment 2 


FC 

2 

Data 

1 

Not Written 

J 


Figure 39. Logical Record Undefined Speci¬ 
fication 

BLOCKED RECORDS, NO FORMAT CONTROL: For 
all blocked records, the record length is 
specified in the LRECL subparameter; the 
block length and buffer length in the 
BLKSIZE subparameter. 

Fixed-Length Records: For blocked fixed- 
length records written without FORMAT 
control, BLKSIZE must be an integral multi¬ 
ple of LRECL, but the logical record length 
can exceed LRECL . The maximum length of 


each record segment is LRECL, including the 
four bytes reserved for the FORTRAN control 
word. 

If the length of a record segment is 
less than LRECL, the rightmost portion of 
the record is padded with zeros (see Figure 
40). Only filled buffers are written; 
partially filled buffers are held for a 
subsequent WRITE (see Figure 40). If a 
subsequent WRITE is not executed before the 
end of the job step, the entire buffer is 
written. 

Example: Assume BLKSIZE=24 and LRECL=12 
10 WRITE(15)A 


WRITE(15)C,B 

Where: A and B are real variables. 

C is a double precision variable. 



I-Record Segment _-—| 

I 1 I 


FC 

4 

4 Bytes 

This space of 12 

Data 

of 

bytes ready for 

2 

Bytes 

Zeros 

next WRITE 


Figure 40. Blocked Logical Records Fixed- 
Length Specification 

Variable-Length Records: For blocked 
variable-length records written without 
FORMAT control, BLKSIZE must be 4 plus an 
integral multiple of LRECL; but the logical 
record length can exceed LRECL. The maxi¬ 
mum data length of each record segment, 
including the FORTRAN control field, is 
(LRECI-4); four bytes are reserved for 
( 11 ) . 

When the space remaining in the buffer 
is less than LRECL, only the filled portion 
of that buffer is written (see Figure 41). 
However, if the space remaining in the 
buffer is greater than or equal to LRECL, 
the buffer is held for a subsequent WRITE 
(see Figure 41). If a subsequent WRITE is 
not executed before the end of the job 
step, the filled portion of the buffer is 
written. 


48 



























Example: Assume BLKSIZE=36 and LRECL=16 
20 WRITE(18)A 


WRITE(18)B 


WRITE(18)E 

Where: A is a double precision variable. 

B and E are real variables. 

I-BLKSIZE-1 

I I 

I I 

U — Logical Record — —I--LRECL-—I 

I I I 


|--LRECL-“|—Record Segment ^ j | 

I III 



H 




FC 

4 

4 Bytes 

LL 

M 

8 Data Bytes 

II 

Data 

Not 


L_ 

LJJ 


0 

Bytes 

Written 


Record Segment ^ + Record Segment 2 = 1 Logical Record 


|-Record Segment 2 - 1 

I I 


— 

— 

FC 

4 

This space of 20 bytes 

LL 

II 

Data 

ready for next WRITE. 



2 

Bytes 

(space > LRECL) 


Figure 41. Blocked Records Variable-Length 
Specification 

BACKSPACE Operations 

Unblocked Records, FORMAT Control: For all 
unblocked records written under FORMAT con¬ 
trol, the volume is positioned so that the 
last record read or written is transmitted 
next. 

Unblocked Records, No FORMAT Control: For 
all unblocked records written without FOR¬ 
MAT control, the volume is positioned so 
that the last logical record read or writ¬ 
ten is transmitted next. 

Blocked Records: The programmer is warned 
against backspacing blocked records; the 
results obtained are unpredictable. 


RECORD LENGTH, BUFFER LENGTH, AND NUMBER OF 
BUFFERS FOR DIRECT ACCESS DATA SETS 

A direct access data set can contain 
only fixed-length, unblocked records. Any 
attempts to read or write any other record 
format by specification in the DCB parame¬ 
ter are ignored. The record length and 
buffer length for a data set are specified 
by the programmer as the record size in the 


DEFINE FILE statement, and cannot be 
changed by specifying the BLKSIZE or LRECL 
subparameters in the DCB parameter. For 
example, the statement: 

DEFINE FILE 8(1000,152,E,INDIC) 

sets the record length and buffer length 
permanently at 152 bytes. The direct 
access data set defined by this DEFINE FILE 
statement contains 1000 fixed-length, 
unblocked records, each record is 152 bytes 
long, and is written under FORMAT control. 

The only DCB parameter that can be 
supplied for direct access data sets is the 
number of buffers: 

BUFN0=x (x—1 or x=2) 

Where: x is the number of buffers used to 

read or write the data set. 

The record format for direct access data 
sets is the same as the format described 
for fixed-length, unblocked records written 
for sequential data sets with one excep¬ 
tion. Records written without FORMAT con¬ 
trol on sequential data sets contain a 
FORTRAN control word. Records written 
without FORMAT control on direct access 
data sets do not contain the FORTRAN con¬ 
trol word. Otherwise, the record format is 
the same for records written without FORMAT 
control: the logical record can exceed the 

record length specified in the DEFINE FILE 
statement, and if a record segment is 
shorter than the record length, the remain¬ 
ing portion of the record is padded with 
zeros (see Figure 42). 

j---Record Length —- 1 

I / 

j— — —-Record Segment 1-j 


20 Data Bytes 

Record Segment 

j + Record Segment ^ ~ 1 Logical Record 

1 

—Record Segment 2 — — —- 1 

1 

4 Data Bytes 

16 Bytes of Zeros 


Figure 42. Logical Record (No FORMAT 
Control) for Direct Access 

Example: A DEFINE FILE statement has speci¬ 
fied the record length for a direct access 
data set as 20. This statement is then 
executed. 

WRITE(9'IX)DPI,DP2,R1,R2 
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Where: DPI and DP2 are double precision 

variables. 

Rl and R2 are real variables. 

IX is an integer variable that 
contains the record position. 


BACKSPACE, END FILE, and REWIND opera¬ 
tions are igndred for direct access data 
sets. 


DCB ASSUMPTIONS FOR LOAD MODULE EXECUTION 

The range of values that may be speci¬ 
fied for BLKSIZE is established for specif¬ 
ic data set reference numbers. If the DCB 
parameter is not specified, default values 
are assumed for BLKSIZE and RECFM (see 
Table 11). 


Table 11. DCB Parameter Defaults and Ranges for Sequential Data Sets 
r- t-t-T" 


Data Set 

Reference Number 


ddname 


BLKSIZE 

Range 2 


Default 

BLKSIZE 


Default 

RECFM 


FTOlFyyy 

FT02Fyyy 


l<x<3624 

l<x<3624 


800 

800 


U 

U 


FT03Fyyy 

FT04Fyyy 


l<x<3624 

l<x<3624 


800 

800 


U 

u 


FT05Fyyy 

FT06Fyyy 


l<x<362 4 
l<x<3624 


80 

136 


r 

UA 1 


7 

8 

99 


FT07Fyyy 

FT08Fyyy 

FT99Fyyy 


l<x<3624 

l<x<3624 

l<x<3624 


80 

800 

800 


F 

u 

U 


h 


H 


*-The first character in the record is for carriage control. 

2 The upper limit for BLKSIZE is established to provide device independence (3624 is the 
maximum number of bytes per track for a 2311) . 



« 
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CATALOGED PROCEDURES 


This section contains figures illustrat¬ 
ing the job control statements used in the 
FORTRAN IV cataloged procedures and a brief 
description of each procedure. The state¬ 
ments used to override the statements and 
parameters in any cataloged procedure are 
also discussed in this section. (The use 
of cataloged procedures is described in 
"FORTRAN Job Processing.") 

Compile 

In each of the three cataloged proce¬ 
dures that include the compile step 
(Figures 44, 45, and 46), the EXEC state¬ 
ment named FORT designates that the operat¬ 
ing system is to execute the program IEY- 
FORT (the FORTRAN compiler). 

The compiler options (shown in Figure 
23) are not supplied with any procedure 
containing a compile step. Therefore, if 
the user wishes to have certain operations 
performed, he must specify those options in 
the job control statements. However, if 
the user does not specify any of the 
options, the system will assume certain 
default options which are noted by the 
underscores in Figure 23. 

The control statements contained in the 
procedure (shown in Figure 43) designate 
the data sets to be used by the compiler 
during its operation. The source listing, 
compile-time information, and error messa¬ 
ges are written on the data set designated 
by the SYSPRINT DD statement. The object 
module resulting from the operation of the 
FORTRAN compiler is written in the tempora¬ 
ry data set 6LOADSET, designated in the 
SYSLIN DD statement. This data set is 
sequential and is assigned to a sequential 
device such as a tape or direct-access 
device. However, if the direct-access 
device is assigned, a primary allocation of 


thirty tracks is requested with a secondary 
allocation of ten tracks. The data set is 
in PASS status and records can be added to 


the data set. 

The 

SYSPUNCH 

DD 

statement 

defines the 

card 

punch to 

be 

used 

in 

obtaining an 

object 

deck. 




The programmer can override 

any 

of 

the 


default options by using an EXEC statement 
which includes the options that are 
desired. 


Compile and Link Edit 

The cataloged procedure to compile the 
source module and link edit the resulting 
FORTRAN object module (FORTGCL) is shown in 
Figure 44. The control statements for 
compilation are the same as described 
above. However, output of the object 
module is defined by the SYSLIN DD state¬ 
ment . 

In each of the cataloged procedures that 
include a link edit step (Figures 44, 45, 
and 46), the EXEC statement named LKED 
specifies that the operating system is to 
execute the program IEWL (the linkage 
editor). However, the linkage editor step 
(or the remainder of the procedure) is not 
executed if a condition code equal to or 
greater than 5 was generated during the 
operation of the compile step in the same 
procedure. 

Execution of the link edit step produces 
a list of the linkage editor control state¬ 
ments (in card image format), a map and 
cross-reference listing of the load module, 
and a list of linkage editor diagnostic 
messages on the data set specified by the 
SYSPRINT DD statement. The load module is 
marked executable even though error condi¬ 
tions are found during processing. 


Sample Coding Form 

i-io_ 

ii 

-20 

21-30 

31-40 

41-50 

51-60 

61-70 

71-80 


nSSQHSBEDHEs] 


n0BH0SH[DEIH 



DBBQSHBEDEIQ 


//FORT, , , EXEC, , 

, ,PGM= 

■IEYFPiRT , , 

i i i i 1 i i i i 


.... 1 ... . 

.... 1 ... . 


//SYSPRINT 

i i i > 1 i i i i 

DD 

i i i i 

, SYS0|UT=A , 

J_1_1_1_1__ l__J _L_1__1_1_1_1_ 

.... 1 ... . 

.... i i . i. 

. . . . 1 . i . i 

.... 1 ... . 


//SYSPUNCH 

i > i i 1 i i i i 

, PP, 

I UNIT 

= SYSC,P 

_i_i_l_i_L_i_i_i_i_ 

1 .... 1 .... 1 

i .... i.... 

_i_i_._i_1_i_._i_i_ 

. i i . 1 . . . . 

i i i i 1 i i i i 

//SYS,LIN 

i i i i 1 i i i i 

DD 

iiii 

, i DSNAME = £L l 0ADSET5DIS i P=,(M0D')PAS ! S,) iUNIT = SY l S i SQi | 

. i . . 1 . . i i 

i i^t .1.11. 

// | 

i_i_i_i___i_i_i_ 


SPACE 

J_1_l_J_1_ 

=.CTR,K 1 , (30, 

. 

i .... i... ■ 

_i_i_i_i_1_i_i_i_._ 

_i_i ._i 1 i ii i 

i . . i 1 i i i i 

I I , ] , , l 

1 1 1 1 1 1 1-L.l-l.l, 1 1 1 1—J-1 1 1 1 In 1 1 1-1—JL_I-1, .. j. . i 1 1 1 1 - L .. 1 1 1 - L, 1 1 1 1 1 - 1_L.. 1 1 1_L_L_J_ 1 1 1 1_L, 1 1 _ I I i 1 I i i I 1 i i i i 1 i ■ i i 


Figure 43. Compile Cataloged Procedure (FORTGC) 
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1-10 

11-20 

21-30 

31-40 

41-50 

51-60 

61-70 

71-80 

Il2l3l4l5l6|7|8l9|0 ! 

II2I3I4I5I6I7I8|9|0 

1121314181617181910 

H2l3l4l5l6l7|8l9lO 

I|2l3l4l5l6l7l8l9[0i 

l|2|3|4|5|6|7|8|9T0 

M2I3I4I5I6I7I8I9I0 

H2I3I4|5I6I7|8I9|0 


Sample Coding Form 


//FORT E.XEC 


PGM -JEYFOR T 


//SYS.PRINT, 


DD 


SYS0,UT*A . 

J_i_i_i i_i_l_l_L. 


//SYSPUNCH, 


DD 


UKJI T^=SY.S C,P 


. 1..-L L.l. I. I_I_ 


//SYS.LIN 

i i i I i i i 


DD 


DSNA,ME-.£LpADS.EjT.?p.IS,PMOjPyPASjS.).UM,!T-SY,S.S.Q^, , , 


// 




l S,PACE | -(TRK|i,(3,0rl0,),), | , 


'pgm=i'ewl^,p'a'rm=('x'ref,ilVst?l'e i t) i ?c 


//LKEjD E 


EC 


//SYS.LIB 

j_i_i_I_i_i_l i 


DD 


DSNA | ME =; 


= SY,S1. FO.RTLIB.iDISP.-OLD 


_J_l_I_I__L. 


//SYS.LMOD 

' J J _t 1_L. «|—1— X. 


DD 


DSMAME-EGfiSET(ftA IN),>DISP | -(NEW,?PASS ) ?UNIT s SYSDA 


// 




l SPACE l -(102 1 4 l (5g | x20 r l l ) i ) 


|//S YS|UT1 


DD 


UNITpSYSD.AiSPA.CE - (1024, ■> (,20012,0)) 


//SYS.PRINT, 


DD 


SYSO,UT=A , 

■ ■ • ■ n ...I. 


i i i i i i i 


i i i i i i i 


//SYS!IN 


DD 


DSNAjME 


=*. i FORT. i SYSLI i N>DISP=(OL i D)DEL;ETE) 


// 


DD 


DDNAME= 

M i l | i i 


SY,SIN 


4- 


i I i i i i 1 l 


■'I'll* 


__L 


Figure 44. Compile ana Link Edit Cataloged Procedure (FORTGCL) 


Sample Coding Form 


1-10 

11-20 

21-30 

31-40 

41-50 

51-60 

61-70 

71-80 

I|2|3|4|5l6|7|8l9l0 

I12|3|4|5|6|7|8l9l0 

l|2|3|4|5|6|7|8]9l 

1 |2|3l4|5|6|7|8l9|0 

1 I2l3l4l5l6|7|8l9l0 

1 |2|3|4|5|6|7|8l9l0 

II2I3I4I5I6I7I81910 1 

l|2|3|4|5|6|7|8|9|0 


//LKE.D EXEC 


P6M»|IE.WL,1|PAR.M-,(.X.REF,iL i IST,t i L.E.T i ),i i CP i N i D,- i ( i S.).L,T.7.FOR,T) 


//SYS.L 1 B , DD 


DSNA|ME 


=SY.S1. FO.RTLI B,iDISP, 

j_i_l_I_i_i_i_ i i _ i__i _l_L ■ ■ • - 1 


=OLD 


//SYS.LMOD , DD 

1 111 I 1 


DSN A,ME=EGOS ET (.MAIN ), j DISP, 

i_i_i_L_J_i_l_l_i_I_i_l_i_J_I_i_l_l_L—l_l_1_i_l_| 


= ( NEW,! PASS,) 


iU 


S|D 


/./, 


.SPACE.=,(,10,2,4,■><,5,0,,2,0, r l,, , , 


i ... i | 

^ w \ \ 


//SYSilTl , DD 


//SYS.PRINT DD 


i U i N i IT | =SY i Sp,A. r S.PA l CE.= i (1024 i 7(|200') i 2,0) i ) 


SYS0UT=A , 

■' 1 1 ■ .4 . ' 1 1 1 1 


//SYS.LIN 

■1 .-L.~L.-L 1.1 l .1. 


DD 


DDNA | ME = S Y I SIN 


//GO 


E.XEC 


//FT05F001 


PGMrft. L,KE,D. SYS.LMOD7|CQKID : 


//FT06F001 


DD 


DD 


| DDNAM I E = SYS | IN , , 


(5 ^ LT^LKEDj) 


J_L_ 


=A 


4 


//FTfl7F001 


DD 


l UNIT= l SYSCP, , 

I 1 1 1 ■ 1 1 1 1 ■ I 1 


Figure 45. Link Edit and Execute Cataloged Procedure (FORTGLG) 


The primary input to the linkage editor 
may consist of concatenated data sets. The 
first, defined by the SYSLIN DD statement, 
is the output of the compiler; the second 
(may be omitted) is the data set defined by 
a LKED.SYSIN DD statement which is speci¬ 
fied by the user and is external to the 
procedure. 

External references made in a FORTRAN 
object module are resolved by the linkage 
editor. Some or all of these references 
can be resolved from the FORTRAN library 
(SYSl•FORTLXB) designated in the SYSLIB DD 
statement. 

During processing, the linkage editor 
requires a work data set which is defined 
by the SYSUT1 DD statement. This data set 
is assigned to a direct-access device with 
primary allocation of two hundred records 
and secondary allocation of twenty records. 


The load module produced by the linkage 
editor is written in the temporary PDS 
Refined in the SYSLMOD DD statement. The 
data set is in the PASS status. 

Link Edit and Execute 

This cataloged procedure, FORTGLG, first 
link edits the FORTRAN object module ana 
then executes the resulting load module. 
(Procedure is shown in Figure 45.) Since 
the link edit step is the first step in the 
procedure, the primary input is the data 
set defined by the LKED.SYSIN DD statement. 

The execute step is included in two 
cataloged procedures (see Figures 45 and 
46). In each of these procedures the 
execute step is invoked by the EXEC state¬ 
ment named GO. However, this step is 
bypassed if a condition code equal to or 
greater than 5 was generated during the 
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operation of the link edit step in this 
procedure. 

Input to the execute step is defined by 
a GO.SYSIN DD statement which is supplied 

• by the user and is external to the proce¬ 
dure. The data set is read using data set 
reference number 5. Execution-time error 
messages are written in the data set 
defined by the SYSPRINT DD statement in the 
link edit step. This data set is associat¬ 
ed with the reference number 6. (Output 
from the load module can also be written in 
f the same data set.) The card punch is 

associated with data set reference number 
7. 

Compile, Link Edit, and Execute 

The cataloged procedure (FORTGCLG) to 
compile, link edit, and execute FORTRAN 
source modules is shown in Figure 46. This 
cataloged procedure consists of the state¬ 
ments in the FORTGC and FORTGLG procedures, 
with the following exception: the SYSLIN DD 
statement defines the output of the compil¬ 
er, and the same statement in the link edit 
step identifies this output as the primary 
input. 

The programmer does not have to define 
the linkage editor input as was required 
for the FORTGLG procedure, but the input 
data set must be defined for the compiler 


so that the source module can be read. A 
data set containing primary input to the 
linkage editor may also be defined by using 
a LKED.SYSIN DD statement. This data set 
is concatenated with the data set contain¬ 
ing the output of the compiler. 


USER CATALOGED PROCEDURES 

The programmer can write his own cata¬ 
loged procedures and tailor them to the 
facilities in his installation. He can 
also permanently modify the IBM-supplied 
cataloged procedures. For information 
about permanently modifying cataloged pro¬ 
cedures, see the System Programmer's Guide . 


OVERRIDING CATALOGED PROCEDURES 

Cataloged procedures are composed of 
EXEC and DD statements. A feature of the 
operating system is its ability to read 
control statements and modify a cataloged 
procedure for the duration of the current 
job. Overriding is only temporary; that 
is, the parameters added or modified are in 
effect only for the duration of the job. 
The following text discusses the techniques 
used to modify cataloged procedures. 


1 -10 

11-20 

21-30 

31-40 

41-50 

w 

1 

o 

o 

61-70 

71-80 
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Sample Coding Form 


//FORT EXEC 


PGM=IEYFO,RT 

j_i_i_i_|_i_i_i—i—I—i—1_ 


//SYSPRINT, DD 


SYS0,UT=A 


//SYSPUNCH, DD 


_J_I_I_ J _I_1_L. 


UNITrSYSCP 

■ ■ ■ ■ 1 ■ ■ _i_i_L' 


_i_i_i_J_i_i_i_i_ 


//SYS.LIN 


DD 


PSNA^E=ELpADS^T? PI S|P=,(MO | D^PAS|S)t 1)^17=SY,SS 


Qi 


X 


//, 


_L 


l SPACE,= (TRK,)(30rl0)) 


ill_I_L 


FORT) 


//LK^D EXEC 


PGM=IEWLrPARM= (XREF iLIST) LET) iCOND = ( 5)L.Ti 

■ 1 _i_J_i_i_L_i_i—i_i__i_i_i_i_L_j_i_I— ,i. j_i_i_i_i_L_i_i_i i 1 j _i_i_i_I_i_ 


//SYS!IB 

i i i I i I_L_ 


DD 


DSNAME 

J_I_ L L _I_L 


= SYjSl.FOiRTLI B,*>DISP;=OLD 


J_I I _I_I_l_l_I_I_I_l_l__I_I_I_I_I—L 


//SYS.LMOD , DD 


DSNA,ME=66 l OSET(,MAIN) | -)DISP l =( NEW> PASS.) i UNIT = 


J_l_l_1_I_l_i_L 


J_l_I_I_l_l_l_ 


SYS,DA 


//, 


, SP ACE,=,(10 2^(5 0,72^1,).) 




J_L_ 


I , I 


//SYSLIT1 

■ _1_1 1 .1_1—1_L 


DD 


UNITrSYSp,A?SPA|CE = (1,02T^(,20012,0) ) 


//SYSPRINT, DD 

i l _I_1 1 1 J_l_1_ ill 


SYS0,UT=A , . , 

i l l i l i i l 1 1 i l i i i I i I I i i i 


i i 1 i i i i I i i i 


//SYSLIN 

_i_i_L_l_I_l_i_1— 


DD 


DSNAME=*. .FORT. ,S YS L^N} DI SjP = ( OL ,D ■> DELATE) 


' M i'' 


J__I_I_I I 


// 


DD 


DDNA,ME=SY,SIN 


iiii 


//GO 


EX,EC 


P6M=*. LKE,D.SYSLMOD vCOND^Y (5>L,T iFORT) ■) (5)L 


iii'i 


i—i—■—i—■— 


TALKED)) 


//FT05F001, DD 

■ ' j _L_i_ l ■ ■ ■ ■ • ' 


DDNA,ME=SY,SIN 


■ i ■ . i 


i i _I_i_i_ 


//FT06F001, DD 


SYS0,UT=A . 

i iii i i 1 


i i i i 1 i i i i i 


//FT07F001, DD 


UNIT,* SYS QP 


_J_i_i__i_i_i_i_I_I_i_I_I__i_i_I_i_I_i_ 






Figure 46. Compile, Link Edit, and Execute Cataloged Procedure (FORTGCLG) 
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Overriding Parameters in the EXEC Statement 

Two forms of keyword parameters 
("keyword" and "keyword.procstep") are dis¬ 
cussed in "Job Control Language." The form 
"keyword.procstep" is used to add or over¬ 
ride parameters in an EXEC statement in a 
cataloged procedure. 

The FORTRAN programmer can, for example, 
add (or override) compiler or linkage edi¬ 
tor options for an execution of a cataloged 
procedure, or he can state different condi¬ 
tions for bypassing a job step. 

Note: When the PARM parameter is overrid¬ 
den, all compiler and/or linkage editor 
options stated in the EXEC statement in the 
procedure step are deleted and replaced by 
those in the overriding PARM parameter. 

Example 1; Assume the cataloged procedure 
FORTGC is used to compile a program, and 
the programmer wants to specify the name of 
his program and the MAP option. The fol¬ 
lowing statement can be used to invoke the 
procedure and to supply the compiler 
options. 

//STEPl EXEC FORTGC, X 
// .PARM.FORT=*MAP,NAME=MYPROG B 

The PARM options apply to the procedure 
step FORT. 

Example 2: Assume the cataloged procedure 
FORTGLG is used to link edit and execute a 
module. Furthermore, the MAP option over¬ 
rides XREF, LET, and LIST in the linkage 
editor step and the COND parameter is 
changed for the execution of the load 
module. The following EXEC statement adds 
and overrides parameters in the procedure. 

//DO EXEC FORTGLG,PARM.LKED=MAP, X 
// COND.GO=(3,LT,DO.LKED) 

The PARM parameter applies to the link¬ 
age editor procedure step LKED, and the 
COND parameter applied to the execution 
procedure step GO. 

Example 3; Assume a source module is 
compiled, link edited, and executed using 
the cataloged procedure FORTGCLG. Further¬ 
more, the linkage editor option MAP is 
specified, and account number 506 is used 
for the execution procedure step. The 
following EXEC statement adds and overrides 
parameters in the procedure. 

//STEPl EXEC FORTGCLG,PARM.LKED=MAP, X 
// ACCT.GO= 50 6 

Overriding and Adding DP Statements 

A DD statement with the name 
"stepname.ddname" is used to override 


parameters in DD statements in cataloged 
procedures, or to add DD statements to 
cataloged procedures. The "stepname" iden¬ 
tifies the step in the cataloged procedure. 
If "ddname" is the name of a DD statement: 


1. Present in the step, the parameters in 
the new DD statement override parame¬ 
ters in the DD statement in the proce¬ 
dure step. 


2. Not present in the step, the new DD 
statement is added to the step. 


In any case, the modification is only 
effective for the current execution of the 
cataloged procedure. 


When overriding, the original DD state¬ 
ment in the cataloged procedure is copied, 
and the parameters specified in it are 
replaced by the corresponding parameters in 
the new DD statement. Therefore, only 
parameters that must be changed are speci¬ 
fied in the overriding DD statement. 


If more than one DD statement is modi¬ 
fied, the overriding DD statements must be 
in the same order as the DD statements 
appear in the cataloged procedure. Any DD 
statements that are added to the procedure 
must follow overriding DD statements. 

When the procedures FORTGC, FORTGCL, and 
FORTGCLG are used, a DD statement must be 
added to define the SYSIN data set to the 
compile step in the procedures (see Figures 
15 and 21). When the procedure FORTGLG is 
used, a DD statement must be added to 
define the SYSLIN data set (see Figure 18). 

When the procedures FORTGCL, FORTGLG, 
and FORTGCLG are used, an overriding DD 
statement can be used to write the load 
module constructed in the linkage editor 
step in a particular PDS chosen by the 
programmer, and assign that member of the 
PDS a particular name. 

During execution of procedure steps, the 
programmer can catalog data sets, assign 
names to data sets, supply DCB information 
for data sets, add data sets, or specify 
particular volumes for data sets by using 
overriding DD statements. 


Example 1: Assume the data sets identified 
by ddnames FT04F001 and FT08F001 are named, 
cataloged, and assigned specific volumes. 
The following DD statements are used to ada 
this information and indicate the location 
of the source module. 
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//J0B1 JOB MSGLEVEL=1 
//STEPl EXEC FORTGCLG 
//FORT•SYSIN DD * 

r-n 

| FORTRAN Source Module | 

L_J 

/* 

//GO.FT04F001 DD DSNAME=MATRIX, X 

// DISP=(NEW,CATLG),UNIT=TAPE r X 

// VOLUME=(PRIVATE,SER=987K) 

//GO.FT08F001 DD DSNAME=INVERT, X 

// DISP=(NEW,CATLG),UNIT=TAPE, X 

// VOLUME=(PRIVATE,SER=1020) 

//GO.SYSIN DD* 

r- 1 

| Input to Load Module | 

l -j 

/* 


Example 2: Assume DCB information is added 
to the DD statement identified by ddname 
FT08F001 and a data set for data set 
reference number 4 is created and cata¬ 
loged. 

//JOB2 JOB 

//STEPl EXEC FORTGLG 
//LKED.SYSIN DD * 


| FORTRAN Object Module 


/* 

//GO•FT04F001 DD DSNAME=FIRING, 

// UNIT=SYSDA,DISP=(NEW,CATLG), 

// SPACE=(100,(2000,200),,,ROUND), 

// VOLUME=(PRIVATE,SER=207H), 

// DCB=(RECFM=VB,LRECL=300,BLKSIZE=604) 

//GO•FT08F001 DD DCB=(RECFM=F,BLKSIZE=200) 
//GO.SYSIN DD * 


r- 1 

| Input to Load Module | 

L_J 

/* 


Example 3: Assume the link edit and exe¬ 
cute cataloged procedure (FORTGLG) is used. 
The load module constructed in the linkage 
editor step is placed in the cataloged 
partitioned data set MATH and is assigned 
the member name DERIV. 

//JOB3 JOB 

//STEPl EXEC FORTGLG 

//LKED•SYSLMOD DD DSNAME=MATH(DERIV), X 


// DISP=(OLD,PASS) 

//LKED.SYSIN DD * 

r - n 

| FORTRAN Object Module | 

L_J 

/* 

//GO.SYSIN DD * 

r-1 

Input to Load Module 

L_J 

/* 


Example 4: Assume the compile, link edit, 
and execute cataloged procedure (FORTGCLG) 
is used with three data sets in the input 
stream: 


1. A FORTRAN main program MAIN with a 
series of subprograms, SUB1 through 
SUBN. 


2. A linkage editor control statement 
that specifies an additional library, 
MYLIB. MYLIB is used to resolve 
external references for the symbols 
ALPHA, BETA, and GAMMA. 


3. A data set used by the load module and 
identified by data set reference num¬ 
ber 5 in the source module. 


The following example shows the deck 
structure. 


//JOBCLG, JOB 00,FORTRANPROG,MSGLEVEL=1 
//HXECCLGX EXEC FORTGCLG 


//FORT. 

SYSIN DD 

* 



i 

i 

i __ _ 

FORTRAN 

Source 

Module 

MAIN 

r 

i 

L 

FORTRAN 

Source 

Module 

SUBl 

r 

i 

i 

i 

i 


• 



r 

1 

L 

FORTRAN 

Source 

Module 

SUBN 


/* 

//LKED.ADDLIB DD DSNAME=MYLIB 
//LKED.SYSIN DD * 

LIBRARY ADDLIB(ALPHA,BETA,GAMMA) 

/* 

//GO.SYSIN DD * 


r- 1 

| Input to Load Module | 

L_J 


/* 


The DD statement FORT.SYSIN indicates to 
the compiler that the source modules are in 
the input stream. The DD statement 
LKED.ADDLIB defines the additional library 
MYLIB to the linkage editor. The DD state¬ 
ment LKED.SYSIN defines a data set that is 
concatenated with the primary input to the 
linkage editor. The linkage editor control 
statements and the object modules appear as 
one data set to the linkage editor. The DD 
statement GO.SYSIN defines data in the 
input stream for the load module. 
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PROGRAMMING CONSIDERATIONS 


This section discusses minimum system 
requirements for the compiler, program 
optimization, updating the FORTRAN library, 
creation of the programmer's private 
library, and limitations of the compiler. 


PROGRAM OPTIMIZATION 

The FORTRAN compiler automatically 
provides optimization of certain areas of 
the source module. Other areas may be 
optimized by the programmer through his use 
of the FORTRAN language. 


STORAGE LOCATIONS AND BYTES 

Storage locations in System/360 are 
called bytes, words, and double-words. One 
word is four bytes long; a double-word is 
eight bytes long. When data is read into 
main storage, it is translated into inter¬ 
nal format. See Table 12 for storage 
allocation according to the type and length 
of the constant or variable. 


Table 12. Storage Allocation 


Type 


h- 

|Logical 


T-T- 

|Length| 

+--f- 

1 |1 byte 

4 j 4 bytes 


Storage 


h- 

j Rea 1 

I 


h- 

|Integer 

i 
i 


j 4 bytes 
|8 bytes 


H 


I-- 

|Complex 


2 |2 bytes (variable 

| only) 

4 |4 bytes 


H 


I-- 

|Character 
j(BCD or EBCDIC) 


8 j 8 bytes 
16 j16 bytes 


H 


|1 character/byte 

I 

- + -^ 

|2 characters/byte | 

_-L-J 


j Hexadecimal 
L_ 


MINIMUM SYSTEM REQUIREMENTS FOR THE FORTRAN 
COMPILER 

The FORTRAN compiler requires at least a 
System/360 Model 40 computer with a minimum 
storage capacity of 128K bytes and a stand¬ 
ard instruction set with the floating-point 
option. 


The following paragraphs describe the 
optimization facilities that are provided 
by the compiler and those defined by the 
programmer. 


DO Loop Optimization 

During the operation of the FORTRAN 
compiler, one complete phase is included 
for the purpose of DO loop optimization. 

Each loop is recorded internally as it 
is encountered in the source module. As 
each step of the optimization process pro¬ 
gresses, the loops are further categorized 
for ease of reference in generating the 
corresponding object code. 

If loops are nested, the end of each 
loop is denoted by a special reserve mark, 
which is placed at the end of the inter¬ 
mediate notation that is being produced. 
The level of nesting is also recorded for 
each group of nested loops. This minimizes 
execution time in determining at object 
time the depth to which calculation must be 
maintained to close the first loop of the 
nest. 

A further categorization divides the 
loops into standard and non-standard. 
Standard denotes the requirements of reg¬ 
ister assignment for the script expression, 
and non-standard denotes the opposite. 
This method enables the compiler to make 
register assignments prior to the final 
generation of the object code. In this 
way, addresses are retrieved and inserted 
into the designated instruction without 
unnecessary repeated address calculation. 


Indicators and Sense Lights 


All programs require a device such as an 
IBM 1052 Keyboard Printer for direct opera¬ 
tor communication. Also, at least one 
direct-access device must be provided for 
system residence. 

The printer must have at least a 
120-character print line. 


At the start of program execution, the 
divide-check indicator, the overflow indi¬ 
cator, and the sense lights are not ini¬ 
tialized. Therefore, if a programmer 
intends to use the indicators or sense 
lights, he should initialize them prior to 
use; otherwise, erroneous results may be 
obtained. 
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use of DUMP and PDUMP 

Under the operating system, a program 
may be loaded into different areas of 
storage for different executions of the 
same job. The following conventions should 
be observed when using the DUMP or PDUMP 
subroutine to insure that the appropriate 
areas of storage ar£ dumped. 


If an array and a variable are to be 
dumped at the same time, a separate set of 
arguments should be used for the array and 
for the variable. The specification of 
limits for the array should be from the 
first element in the array to the last 
element. For example, if an array TABLE is 
dimensioned as: 

DIMENSION TABLE (20) 

The following statement could be used to 
dump TABLE and the real variable B in 
hexadecimal format and terminate execution 
after the dump is taken: 

CALL DUMP (TABLE(1),TABLE(20) r 0,B,B,0) 


If an area in COMMON is to be dumped at 
the same time as an area of storage not in 
COMMON, the arguments for the area in 
COMMON should be given separately. For 
example, if A is a variable in COMMON, the 
following statement could be used to dump 
the variables A and B in real format 
without terminating execution: 

CALL PDUMP (A,A,5,B,B,5) 


If variables not in COMMON are to be 
dumped, the programs should list each vari¬ 
able separately in the argument list. For 
example, if R, P, Q are defined implicitly 
in the program, the statement: 

CALL PDUMP(R,R,5,P,P,5,Q,Q,5) 

should be used to dump the three variables. 
If the statement: 

CALL PDUMP(R,Q,5) 

is used, all main storage between R and Q 
is dumped. 


If an array and a variable are passed as 
arguments to a subroutine, the arguments in 
the call to DUMP or PDUMP in the subroutine 
should specify the parameters used in the 
definition of the subroutine. For example, 
if the subroutine SUBI is defined as: 

SUBROUTINE SUBI(X,Y) 

DIMENSION X(10) 


and the call of SUBI within the source 
module is: 

DIMENSION A(10) 


10 CALL SUBI(A,B) 

then the following statement in the subrou¬ 
tine should be used to dump the variables 
in hexadecimal format without terminating 
execution: 

CALL PDUMP (X(l),X(10),0,Y,Y,0) 

If the statement: 

CALL PDUMP (X(1),Y,0) 

is used, all storage between A(l) and Y is 
dumped, due to the method of transmitting 
arguments. (Y does not occupy the same 
storage location as B.) 


Direct Access Programming 

Using direct access I/O rather than 
sequential I/O can decrease loaa module 
execution time: the direct access state¬ 
ments in the FORTRAN IV language enable the 
programmer to retrieve a record from any 
place on the volume without reading all the 
records preceding that record in the data 
set. 


Not all applications are suitea to 
direct access I/O, but an application that 
uses a large table that must be held in 
external storage can use direct access I/O 
effectively. An even better example of a 
direct access application is one that uses 
a data set that is updated frequently. 
Records in the data set that are updated 
frequently are called master records . 
Records in other data sets used to update 
the master records are called detail 
records. 


Each of the master records should con¬ 
tain a unigue identification that distin¬ 
guishes this record from any other master 
record. Detail records used to update the 
masters should contain an identification 
field that identifies a detail record with 
a master record. For example, astronomers 
might have assigned unique numbers to some 
stars, and they wish to collect data for 
each star on a data set. The unique number 
for each star can be used as identification 
for each master record, and any detail 
record used to update a master record for a 
star would have to contain the same number 
as the star. 


Programming Considerations 
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A FORTRAN program indicates which record 
to FIND, READ or WRITE by its record 
position within the data set. The ideal 
situation would be to use the unique record 
identification as the record position. 
However, in most cases this is impractical. 
The solution to this problem is a randomiz¬ 
ing technique. A randomizing technique is 
a function which operates on the identifi¬ 
cation field and converts it to a record 
position. For example, if six-digit num¬ 
bers are assigned to each star, the random¬ 
izing technique may truncate the last two 
digits of the number assigned to the star 
and use the remaining four digits as a 
record position. For example, star number 
383320 would be assigned position 3833. 
Another example of a randomizing technique 
would be a mathematical operation performed 
on the identification number, such as 
squaring the identification number and 
truncating the first four digits and the 
last four digits of the result. Then the 
record for star number 383320 is assigned 
record position 3422. There is no general 
randomizing technique for all sets of iden¬ 
tification numbers. The programmer must 
devise his own technique for a given set of 
identification numbers. 

Two problems arise when randomizing 
techniques are used. The first problem is 
that there may be a lot of space wasted on 
the volume. The solution in this instance 
must be developed within the randomizing 
technique itself. For example, if the last 
two digits on the identification numbers 
for stars are truncated and no star numbers 
begin with zero, the first thousand record 
positions are blank. Then a step should be 
added to the randomizing technique to sub¬ 
tract 999 from the result of the trunca¬ 
tion . 

The second problem is that more than one 
identification may randomize to the same 
record location. For example, if the last 


two digits are truncated, the stars iden¬ 
tified by numbers 383320, 383396, and 
383352 randomize to the sarnie record loca¬ 
tion - 3833. Records that randomize to the 
same record location are called synonyms . 
This problem can be solved by developing a 
different randomizing technique. However, 
in some situations this is difficult, and 
the problem must be solved by chaining. 

Chaining is arranging records in a 
string by reserving an integer variable in 
each record to point to another record. 
This integer variable will contain either 
an indicator showing that there are no more 
records in this chain, or the record loca¬ 
tion cf the next record in the chain. 
Records chained together are not adjacent 
to each other. Figure 47 shows the records 
for star numbers 383320, 383396, and 
383352. 

When records are chained, the first 
record encountered for a record position is 
written in the record position that result¬ 
ed from randomizing the identification num¬ 
ber. Any records that then randomize to 
that same record location must be written 
in record positions to which no other 
record identifications randomize. The 
space for these synonyms can be allocated 
either at the end or the beginning of the 
data set. However, this space must be 
allocated when the data set is first writ¬ 
ten. For example, if the randomizing tech¬ 
nique assigns master records to record 
locations between 1 and 9999, the program¬ 
mer may wish to reserve record locations 
10000 to 12000 for master records that 
become synonyms. 

The programmer must keep a record loca¬ 
tion counter to keep track of the space 
assigned for synonyms. When a synonym is 
inserted in this space, the record location 
counter must be incremented. The program¬ 
mer should set up a dummy record in his 


Identifier Chain 

r- t-t-i 

| | Record | | 

I 383320 jPosition for| Data | 

I I 383396 | | 

l-1--j --L-J 

r- t-t-1 

| | Record | | 

j 383396 jPosition for| Data | 

| | 383352 | | 

L-x-,--L-J 

t- T-- -- 

| | End | | 

| 383352 | of | Data | 

j j Chain | | 

l _r_x_ j 

Figure 47. Record Chaining 
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data set to maintain this record location 
counter. When the direct access data set 
is created, the record location counter 
should be set at the lower limit of the 
record positions available for synonyms 
(i.e., record location 10000 in the example 
used above). 

Also an indicator should be reserved to 
indicate to the program that the end of a 
chain has been reached. Since no record 
position is designated as 0, 0 can be used 
to indicate the end of a chain. 

Before a FORTRAN program writes a direct 
access data set for the first time, the 
data set must be created by writing 
"skeleton records" in the space that is to 
be allocated for the direct access data 
set. These skeleton records should be 
written by an installation-written program. 
After the skeleton records are written, the 
direct access data set must be classified 
as OLD in the DISP parameter of the DD 
statement. However, if the skeleton 
records are not written before direct 
access records are written by the FORTRAN 
program for the first time, a FORTRAN load 
module automatically creates the data set 
and writes the skeleton records. The pro¬ 
grammer indicates that skeleton records 
have not been written by specifying NEW in 
the DISP parameter. A FORTRAN load module 
writes skeleton records according to the 
format described in "WRITE — Create a 
Direct Organization Data Set - Format F 
Records" in "Section 3, Basic Sequential 
Access Method (BSAM)" in the Control Pro¬ 
gram Services publication. 

Figure 48 shows a block diagram of the 
logic that can be used to write a direct 
access data set for the first time. The 
block diagram does not show any attempt to 
write skeleton records. 

Example 3 in Appendix B shows a program 
and job control statements used to update a 
direct access data set. 


Direct Access Programming Considerations 

Space must be allocated in the SPACE 
parameter of the DD statement for a data 
set written on a direct access volume. For 
direct access data sets, the space allocat¬ 
ed in the SPACE parameter should be consis¬ 
tent with the record length and number of 
records specified in the DEFINE FILE state¬ 
ment in the FORTRAN program. For example, 
in the DEFINE FILE statement 

DEFINE FILE 8(1000,40,E,I) 

the number of records is specified as 1000 
and the record length is specified as 40. 
When this program is executed the DD state¬ 


ment for this data set should contain the 
SPACE parameter 

SPACE=(40,(1000)) 

indicating that space is allocated for 1000 
records, and 40 bytes for each record. 



Figure 48. Writing a Direct Access Data 
Set for the First Time 

The DEFINE FILE statement for a data set 
does not have to be in the same source 
module in which I/O operations occur. For 
example, the DEFINE FILE statement can be 
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given in a main program with a subprogram 
performing the I/O operations on the data 
set. However, the associated variable in 
the DEFINE FILE statement is only changed 
by I/O operations performed in the source 
module in which the DEFINE FILE statement 
occurs. Even if the associated variable is 
passed in COMMON, the associated variable 
is changed only by I/O operations that 
occur in the source module in which the 
DEFINE FILE statement appears. 

An associated variable should not be 
passed as a parameter between a main pro¬ 
gram and its subprograms because the asso¬ 
ciated variable is not passed in the same 
way that other variables are passed. Other 
variables reflect the result of any opera¬ 
tions performed on them in the subprogram. 
An associated variable is not changed by 
operations performed on it in the subpro¬ 
gram. 

The FIND statement permits record 
retrieval to occur concurrently with compu¬ 
tation or I/O operations performed on dif¬ 
ferent data sets. By using the FIND state¬ 
ment, load module execution time can be 
decreased. For example, the statements 

10 A=SQRT(X) 


52 E=ALPHA+ BETA* SIN(Y) 

64 WRITE(9)A,B,C,D,E 
76 READ(8 , 101)X,Y 

are inefficient because computations are 
performed between statements 10 and 52 and 
an I/O operation is performed on another 
data set while record number 101 could be 
retrieved. If the following statements are 
substituted, the execution of this module 
becomes more efficient because record num¬ 
ber 101 is retrieved during computation and 
I/O operations on other data sets. 

5 FIND(8'101) 

10 A=SQRT(X) 


52 E=ALPHA+BETA*SIN(Y) 
65 WRITE(9)A,B,C,D,E 
76 READ(8 f 101)X,Y 


COMPILER RESTRICTIONS 


• The maximum level of nesting for DO 
loops and implied DOs is 25. 

• The maximum number of expressions and 
statement functions that can be nested 
is 100. 


• The maximum number of source cards for 
one compilation is dependent upon the 
amount of storage available to the 
compiler. A 400 statement program will 
require approximately 8OK bytes for the 
compiler plus workspace, while a 2000 
statement program requires approximate¬ 
ly 18OK bytes. 


LIBRARY CONSIDERATIONS 

The FORTRAN library is a group of sub¬ 
programs residing in the partitioned data 
set SYS1.FORTLIB. For a detailed descrip¬ 
tion of the FORTRAN library, see the FOR¬ 
TRAN IV Library Subprograms publication. A 
programmer can change the subprograms in 
the library; he can add, delete, or substi¬ 
tute library subprograms; or he can create 
his own library. These topics are dis¬ 
cussed in detail in the Utilities publica¬ 
tion. 


ED STATEMENT CONSIDERATIONS 

Several DD statement parameters and sub¬ 
parameters are provided for I/O optimiza¬ 
tion (see Figure 49). Other DD statement 
parameters are discussed in "Job Control 
Language” and "Creating Data Sets.” 

Channel Optimization 

The SEP parameter indicates that I/O 
operations for specified data sets are to 
use separate channels (channel separation), 
if possible. The I/O operations for the 
data set, defined by the DD statement, in 
which 


SEP=(ddname[,ddnarne]...) 

appears, are assigned to a channel differ¬ 
ent from those assigned to the I/O opera¬ 
tions for data sets defined by the DD 
statements "ddname". Assigning data sets 
j^hose I/O operations occur at the same time 
to different channels increases the speed 
of I/O operations. 

I/O Device Optimization 

UNIT subparameters can be specified for 
device optimization. 


VOLUME MOUNTING AND DEVICE SEPARATION: 


UNIT=(name 



[, DEFER] 


[,SEP=(ddname[,ddname]...)]) 


can be specified for volume mounting and 
device separation. The "name" and number 
of units are discussed in the section "Data 
Definition Statement." 
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SEP=(ddname[,ddname]. • . 1 ) 2 

( (nainet, n|P 3 ][,DEFER][,SEP=(ddname[,ddname]... 1 ) 2 ] u 5 ) e ) 
UNIT=lAFF=ddname / 

SPACE=(ABSTR,(quantity,beginning-address[,directory-quantity]) ) 


t 


SPLIT 


= (n {, 


CYL l 1 

average-record-lengthf,(primary-quantity[,secondary-quantity]) ) 


(TRK , 

SUBALLOC=(jCYL (,(primary-quantity(,secondary-quantity] 

( average-record-length) 

(ddname ^ 

[,directory-quantity]),]stepname.ddname () 

(stepname.procstep.ddname) 



iThe maximum number of repetitions allowed is 7. 

2 If only one "ddname" is specified, the delimiting parentheses may be omitted. 

3 If neither "n" nor "P" is specified, 1 is assumed. 

‘♦This subparameter is applicable only for direct-access devices. 

5 This subparameter is the only keyword subparameter shown in this figure. All the| 
remaining subparameters shown in the UNIT, SPACE, SPLIT, and SUBALLOC parameters arej 
positional subparameters. 

6 If only "name" is specified, the delimiting parentheses may be omitted. 


Figure 49. DD Statement Parameters for Optimization 


DEFER 

indicates that the volume(s) for the 
data set need not be mounted until 
needed. The control program notifies 
the operator when to mount the volume. 
Deferred mounting cannot be specified 
for a new output data set on a direct- 
access device. 

SEP=(ddname(,ddname]. . . ) 

is used when a data set is not 
assigned to the same access arms on 
direct-access devices as the data sets 
identified by the list of ddnames. 
This subparameter is used to decrease 
access time for data sets and is 
meaningful only for direct-access 
devices. The operating system honors 
the request for device separation if 
possible, but ignores the SEP sub¬ 
parameter if an insufficient number of 
access arms are available. the SEP 
subparameter in the UNIT parameter 
provides for device separation, while 
the SEP parameter provides for channel 
separation. 


DEVICE AFFINITY: The use of the same 

device by data sets is specified by: 

UNIT=AFF=ddname 

The data set defined by the DD statement in 
which this UNIT parameter appears uses the 
same device as the data set defined by the 
DD statement "ddname" in the current job 
step. 


Direct-Access Space Optimization 

The SPACE parameter can be used to 
specify space beginning at a designated 
track address on a direct-access volume. 
The SPLIT or SUBALLOC parameters may be 
specified instead of SPACE to split the use 
of cylinders among data sets on a direct- 
access volume or to use space specified for 
another data set which it did not use. 
(The other SPACE parameter is discussed in 
"Creating Data Sets.") 

SPACE BEGINNING AT A SPECIFIED ADDRESS: 

SPACE=(ABSTR,quantity,beginning-address 
[,directory-quantity]) 
specifies space beginning at a 
particular track address on a direct- 
access volume. The "quantity" is the 
number of tracks allocated to the data 
set. The "beginning address" is the 
relative track address on a direct- 
access volume where the space begins. 
If the data set is a new partitioned 
data set, the "directory quantity" 
specifies the number of 256-byte 
blocks that are allocated to the 
directory of a new PDS. 

SPLITTING THE USE OF CYLINDERS AMONG DATA 
SETS: If several data sets use the same 

direct-access volume in a job step, proc¬ 
essing time can be saved by splitting the 
use of cylinders among the data sets. 
Splitting cylinders eliminates seek opera¬ 
tions on separate cylinders for different 
data sets. Seek operations are measured in 
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milliseconds, while the data 
measured in microseconds. 


transfer is 


SPLIT 


= (n j. 


CYL 


average-record-length[ 


,(primary-quantity 
[,secondary-quantity] 


»]» 


is substituted for the SPACE parameter when 
the use of cylinders is split. If CYL is 
specified, "n" indicates the number of 
tracks per cylinder to be used for this 
data set. If "average record length" is 
specified, "n" indicates the percentage of 
tracks per cylinder used for this data set. 
The remaining subparameters are the same as 
those specified for SPACE in "Creating Data 
Sets." 

More than one DD statement in a step 
will use the SPLIT parameter. However, 
only the first DD statement specifies all 
the subparameters; the remaining DD state¬ 
ments need only specify "n". For example: 

//STEP4 EXEC PGM=TESTFI 

//FT08F001 DD SPLIT=(45,800,(100,25)) 

//FT17F001 DD SPLIT=(35) 

//FT23F001 DD SPLIT=(20) 


ACCESSING UNUSED SPACE: Data sets in pre¬ 
vious steps may not have used all the space 
allocated to them in a DD statement. The 
SUBALLOC parameter may be substituted for 
the SPACE parameter to permit a new data 
set to use this unused space. 


(TRK ^ 

SUBALLOC=(<CYL ( 

(average-record-length( 


(primary-quantity, 

[,secondary-quantity] 

[,directory-quantity]), 

C ddname ) 

< stepname.ddname > ) 

( stepname.procstep,ddname ) 

The data set from which unused space is 
taken is defined in the DD statement 
"ddname", which appears in the step 

"stepname." (The step must be in the 
current job.) The other subparameters 
specified in the SUBALLOC parameter are the 
same as the subparameters described for 
SPACE in "Creating Data Sets." 


62 



SYSTEM OUTPUT 


The compiler, linkage editor, and load 
module produce aids which may be used to 
document and debug programs. This section 
describes the listings, maps, card decks, 
and error messages produced by these compo¬ 
nents of the operating system. 


COMPILER OUTPUT 

A listing of the source statements, a 
table of the source module names, an object 
module listing, and an object module card 
deck will be generated by the compiler, 
depending on the options specified by the 


user. Source module diagnostic messages 
are also produced during compilation. 


Source Listing 

If the SOURCE option is specified, the 
source listing is written in the data set 
specified by the SYSPRINT DD statement. An 
example of a source module listing is shown 
in Figure 51. This printout is the source 
listing of the sample program illustrated 
in Figure 50. (This program will be used 
throughout the remainder of the publication 
for purposes of example illustration.) 
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Figure 50. Sample FORTRAN IV Program 
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Storage Map 

If the MAP option is specified, a table 
is generated for each of seven classifica¬ 
tions of variables used in the source 
module. Each table contains the names and 
locations of variables used in that partic¬ 
ular context. The classifications are as 
follows: 


• COMMON variables 

• EQUIVALENCE variables 

• Scalar variables 

• Array variables 

• Subprograms called 

• NAMELIST variables 

• FORMAT statements 


Separate maps are produced for each 
classification, with the appropriate head¬ 


ing preceding the data. The variable 
names, statement labels or subprogram names 
are arranged across the page; six to a 
line. However, storage maps of variables 
not used in the source module are not 
produced. 


Figure 52 is an example of a storage map 
produced for the sample program in Figure 
50. 


Object Module Listing 

If the LIST option is specified, an 
object module listing is produced. An 
example of an object module listing is 
given in Figure 53. 



e 

PRIME NUMBER PROBLEM 


0001 

100 

WRITE (6,8) 


0002 

8 

FORMAT (52H FOLLOWING IS A LIST OF 

PRIME NUMBERS FROM 1 TO 1000/ 


119X,1H1/19X,1H2/19X,1H3) 


0003 

101 

1 = 5 


0004 

3 

A = I 


0005 

102 

A=SQRT(A) 


0006 

103 

J=A 


0007 

104 

00 1 K=3,J,2 


0008 

105 

L = I/K 


0009 

106 

IF(L*K-I)1,2,4 


C010 

1 

CONTINUE 


0011 

107 

WRITE (6,5)1 


0012 

5 

FORMAT (120) 


0013 

2 

1 = 1 + 2 


0014 

108 

IF(1000—I)7,4,3 


0015 

4 

WRITE (6,9) 


0016 

9 

FORMAT (14H PROGRAM ERROR) 


0017 

7 

WRITE (6,6) 


0018 

6 

FORMAT (31H THIS IS THE END OF THE 

PROGRAM) 

CC19 

109 

STOP 


0020 


END 



Figure 51. Source Module Listing 
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Figure 52. Storage Map 
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LOCATION 

STA NUM 

LABEL 

OP 

OPERAND 

BCD OPERAND 

COOOOO 



BC 

15,12(0,15) 


C0C004 



DC 

06D4C1C9 


C0C008 



DC 

D5404040 


GOOOOC 



STM 

14,12,12(13) 


000010 



LM 

2,3,40(15) 


000014 



LR 

4,13 


CC0016 



L 

13,36(0,15) 


00001A 



ST 

13,8(0,4) 


CC001E 



STM 

3,4,0(13) 


000022 



BCR 

15,2 


000024 



DC 

00000000 

A4 

000028 



DC 

00000000 

A20 

00002C 



DC 

00000000 

A36 

000198 


A36 

L 

13,4(0,13) 


00019C 



L 

14,12(0,13) 


0001A0 



LM 

2,12,28(13) 


0001A4 



MVI 

12(13),255 


0001A8 



BCR 

15,14 


0001AA 


A20 

L 

15,160(0,13) 

I BCOM = 

0001 A E 



LR 

12,13 


000180 



LR 

13,4 


000 IB 2 



BAL 

14,64(0,15) 


0001B6 



LR 

13,12 


C001B8 

1 

100 

L 

15,160(0,13) 

IBCOM= 

0001BC 



BAL 

14,4(0,15) 


0CC1C0 



DC 

00000006 


0001C4 



DC 

OOOOOODC 


000 1C8 



L 

15,160(0,13) 

I BCOM = 

C001CC 



BAL 

14,16(0,15) 


000 IDO 

3 

101 

L 

0,344(0,13) 


0001D4 



ST 

0,140(0,13) 

I 

C001D8 

4 

3 

L 

0,140(0,13) 

I 

0001CC 



LPR 

1,0 


000 IDE 



ST 

1,324(0,13) 


C001E2 



LD 

0,320(0,13) 


0001E6 



AD 

0,304(0,13) 


0001EA 



LTR 

0,0 


COO 1EC 



BALR 

14,0 


0001EE 



BC 

11,6(0,14) 


000 IF2 



LCDR 

0,0 


0001F4 



STE 

0,144(0,13T 

A 

CC01F8 

5 

102 

LA 

1,168(0,13) 


0001FC 



L 

15,164(0,13) 

SQRT 

0C0200 



BALR 

14,15 


C00202 



STE 

0,144(0,13) 

A 

000206 

6 

103 

SDR 

0,0 


C00208 



LE 

0,144(0,13) 

A 



Figure 53. Object Module Listing 
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00020C 



AM 

0 f336(0,13) 


CC0210 



STD 

0,328(0,13) 


000214 



L 

0,332(0,13) 


000218 



LTDR 

0,0 


000214 
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K 
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ST 
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L 

C0023E 

9 
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L 
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L 
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M 
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K 
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S 
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I 
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2 
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4 
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L 

3,148(0,13) 

J 
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DC 
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END 



TOTAL MEMORY REQUIREMENTS 

0002E6 BYTES 


Figure 53. 

Object Module 

Listing 

(Continued) 




66 





Object: Module Card Deck 


If the DECK option is specified, an 
object module card deck is produced. This 
deck is made up of four types of cards — 
TXT, RLD, ESD, and END. A functional 
description of these cards is given in the 
following paragraphs. 


OBJECT MODULE CARDS: Every card in the 
object module deck contains a 12-2-9 punch 
in column 1. The identifier consists of 
the characters ESD, RLD, TXT or END in 
columns 2 through 4. The first four char¬ 
acters of the name of the program are 
placed in columns 73 through 76 with the 
sequence number of the card in columns 
77-80. 


ESD CARD: Four types of ESD cards are 

generated as follows: 

ESD, type 0 - contains the name of the pro¬ 
gram and indicates the begin¬ 
ning of the object module. 
The name is the module name 
followed by a #. 

ESD, type 1 - contains the entry point 
(where control is given to 
begin execution of the 
module). The entry point is 
the module name on a SUBROU¬ 
TINE or FUNCTION statement, 
or the name specified in the 
NAME option, or the name 
MAIN. 

ESD, type 2 - contains the names of subpro¬ 
grams referred to in the 
source module by CALL state¬ 
ments, EXTERNAL statements, 
explicit function references, 
and implicit function ref¬ 
erences . 

ESD, type 5 - contains information about 
each COMMON block. 

The number 0, 1, 2, or 5 is placed in card 

column 25. 


RLD CARD: An RLD card is generated for 
external references indicated in the ESD, 
type 2 cards. To complete external ref¬ 
erences, the linkage editor matches the 
addresses in the RLD card with external 
symbols in the ESD card. When external 
references are resolved, the storage at the 
address indicated in the RLD card contains 
the address assigned to the subprogram, 
indicated in the ESD, type 2 card. RLD 
cards are also generated for a branch list 
produced for statement numbers. 


TXT CARD: The TXT card contains the con¬ 
stants and variables used by the programmer 
in his source module, any constants and 
variables used by the programmer in his 
source module, any constants and variables 
generated by the compiler, coded informa¬ 
tion for FORMAT statements, and the machine 
instructions generated by the compiler from 
the source module. 


END CARD: One END card is generated for 
each compiled source module. This card 
indicates the end of the object module to 
the linkage editor, the relative location 
of the main entry point, and the length (in 
bytes) of the object module. 


OBJECT MODULE DECK STRUCTURE: Figure 54 
indicates the FORTRAN object module deck 
structure. 



t TXT Cards for (1 

Subprogram 


Addresses 

l 

TXT Cards for ( 

P 



Figure 54. Object Module Deck Structure 
Source Module Diagnostics 


Two types of diagnostic messages are 
written by the compiler — error/warning 
messages and status. 
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Source Module Error/Warninq Messages: The 

error/warning messages produced by the com¬ 
piler are noted on the source listing 
immediately after the statement in which 
they occur. A maximum of four messages 
appears on each line. Figure 55 illus¬ 
trates the format of the messages as they 
are written in the data set specified by 
the SYSPRINT DD statement. 

There are two types of error/warning 
messages: serious error messages, and warn¬ 
ing messages. The serious error messages 
have a condition code of eight and the 
warning messages a code of four or zero. 

For a description of error/warning mes¬ 
sages, see Appendix D. 

r- n 

|XX = A+B+-C/(X**3-A**-75) | 

i $ $ i 

i i 

|n) y message, n) y message 

I I 

|Where: n is an integer noting the posi-| 

I tional occurrence of the error onj 

| each card. j 

I I 

y is a l-to-3 digit message num-| 
ber in IEYxxxI format. | 

i f 

| $ is the symbol used by the| 

j compiler for flagging the partic-| 

j ular error in the statement (this) 

symbol is always noted on thej 
line following the source state-j 
ment and underneath the error). | 

i i 

message is the actual message| 
printed | 

l_J 

Figure 55. Format of Diagnostic Messages 

Status Messages: During operation of the 

compiler, messages- may occur which indicate 
termination of compilation. These messages 
are noted as a result of internal compiler 
errors which render continuation of compi¬ 
lation impossible. These messages are ter¬ 
minal error messages and have a condition 


code of 16. For a description of these 
messages see Appendix D. 

LINKAGE EDITOR OUTPUT 

The linkage editor produces a map of a 
load module if the MAP option is specified, 
or a map and a cross-reference list if the 
XREF option is specified. The linkage 
editor also produces diagnostic messages, 
which are discussed in the Linkage Editor 
publication. 

Module Map 

The module map is written in the data 
set specified in the SYSPRINT DD statement 
for the linkage editor. To the linkage 
editor, each program (main or subprogram) 
and each COMMON (blank or named) area is a 
control section. 

Each control section name is written 
along with origin and length of the control 
section. For a program and named COMMON, 
the name is listed; for blank COMMON, the 
name $BLANKCOM is listed. The origin and 
length of a control section is written in 
hexadecimal numbers. A segment number is 
also listed for overlay structures (see the 
Linkage Editor publication). 

For each control section, any entry 
points and their locations are also writ¬ 
ten; any functions called from the data set 
specified by the SYSLIB DD statement are 
listed and marked by asterisks. 

The total length and entry point of the 
load module are listed. 

Figure 56 shows a load module map for 
the Sample Program shown in Figure 50. 

Cross-Reference List 

If the option XREF is specified, a 
cross-reference list is written with the 
module map. This cross-reference list 
gives the location from which an external 
reference is made, the symbol externally 


CONTROL SECTION ENTRY 


NAME 

ORIGIN 

LENGTH 

NAME 

LOCATION 

M A I N = 

00 

2E6 

MAIN 

00 

IFCFCCMh* 

2 E 8 

FB3 

IBC 0M= 

2E8 

IHCSSQRT* 

12 AO 

AC 

SORT 

12 A0 

IFCFCVTF* 

1350 

FEB 

ADC 0N = 

1350 




FCVIO 

1 8D8 

IHCFIOSH* 

2340 

C30 

FIOCS= 

2340 

IHCUATBL* 

2F70 

108 




NAME 

LOCATION 

NAME 

LOCATION 

NAME 

LOCATION 

F D10C S= 

3A4 





FCVZO 

FCVEO 

149C 
1072 

FCVAO 

FCVC0 

1542 

1F6C 

FCVLQ 

1 5C A 


Figure 56. Module Map 
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LCCAT ION REFERS 

TO SYMBOL 

IN CONTROL SECTION 

DO 

I BC0M = 

IHCFC0MH 

D4 

SQRT 

IHCSSQRT 

1134 

ADC0N= 

IHCFCVTH 

112C 

F IOC S = 

IHCFI0SH 

1138 

FCVEO 

IHCFCVTH 

113C 

FCVLO 

IHCFCVTH 

1140 

FCVIO 

IHCFCVTH 

1144 

FCVCO 

IHCFCVTH 

1148 

FCVAO 

IHCFCVTH 

114C 

FCVZO 

IHCFCVTH 

1324 

I BCQM = 

IHCFCCMH 

21FC 

I BCGM = 

IHCFC0MH 

2464 

IHCUATBL 

IHCUA.TBL 

2470 

IBCGM= 

IHCFCOMH 

ENTRY ADDRESS 

00 


TOTAL LENGTH 

3078 



Figure 57. Linkage Editor Cross-Reference 
List 

referenced in this control section, the 
control section in which the symbol 
appears, and the segment number of the 
control section in which the symbol 
appears. Unless the linkage editor is 
building an overlay structure, the cross- 
reference list appears after the module map 
for all control sections. 

Figure 57 shows the cross-reference list 
for the Sample Program shown in Figure 50. 

LOAD MODULE OUTPUT 

The programmer defines the output data 
sets for load module execution in READ, 
WRITE, and FORMAT statements. At execution 
time, FORTRAN load module diagnostics are 
generated in three forms — error code 
diagnostics, program interrupt messages, 
and operator messages. An error code indi¬ 
cates an input/output error or a misuse of 
a FORTRAN library function. A program 
interrupt message indicates a condition 
that is beyond the capacity of System/360 
to correct. An operator message is gener¬ 
ated when a STOP or PAUSE is executed. 

Error Code Diaqnotics 


code is the number specified by the digits 
xxx. These error codes are described in 
Appendix D. If any errors are detected, 
execution of the job step is terminated and 
a condition code of 16 is returned to the 
operating system. 

Program Interrupt Messages 

Program interrupt messages containing 
the old Program Status Word (PSW) are 
produced when one of the following occurs: 

• Fixed-Point Divide Exception (9) 

• Exponent-Overflow Exception (C 

• Exponent-Underflow Exception (D) 

• Floating-Point Divide Exception (F) 

Operator intervention is not required 
for any of these interruptions, and execu¬ 
tion is not terminated. Figure 58 shows 
the interruption message format. 

The program interrupt messages are writ¬ 
ten on the error message data set specified 
by the programmer. (See FORTRAN Job 
Processing”.) 

The four characters in the PSW (i.e., 9, 
C, D, or F) represent the code number (in 
hexadecimal) associated with the type of 
interruption. 

ABEND Dump 

If a program interrupt occurs that caus¬ 
es abnormal termination of a load module, 
an indicative dump is given (i.e., only the 
contents of significant registers, indica¬ 
tors, etc., are dumped). However, if a 
programmer adds the statement 

//GO.SYSABEND DD SYSOUT=A 

to the execute step of a cataloged proce¬ 
dure, main storage and significant reg¬ 
isters, indicators, etc., are dumped. (For 
information about interpreting an ABEND 
dump, see the Control Program Messages, 
Completion Codes, and Storage Dumps publi¬ 
cation. 


When an error condition arises during 
execution of a FORTRAN load module, a 
message of the form 

IHCxxxI 

is written on the error message data set 
(see "FORTRAN Job Processing"). The error 


Operator Messages 

A message is transmitted to the operator 
when a STOP or PAUSE is encountered during 
load module execution. Operator messages 
are written on the device specified for 
operator communication. For a description 
of these messages, see Appendix D. 


i 
i 

|IHC210I PROGRAM INTERRUPT - OLD PSW IS xxxxxxxjD(xxxxxxxx 

I 


Figure 58. Program Interrupt Message 
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APPENDIX A: INVOKING THE FORTRAN COMPILER 


FORTRAN can be invoked by a problem 
program through the use of the CALL, 
ATTACH, or LINK macto-instructions. 

The program must supply to the FORTRAN 
compiler: 

• The information usually specified in 
the PARM parameter of the EXEC state¬ 
ment, 

• The ddnames of the data sets to be used 
during processing by the FORTRAN com¬ 
piler. 


T T 

Name |Operation|Operand 

[name] j fLXNK \ 

|EP=IEYFORT 

j |ATTACH 1 
1 ' ' 

j PARAM=(optionaddr 
| [, ddnameaddr]) ,*VL=1 

i 

1 

[name]|CALL 

1 

1 

1 

|IEYFORT 

| PARAM=(optionaddr 
| [,ddnameaddr]),VL 

-L 

-L 


optionaddr 

specifies the address of a variable 
length list containing information 
usually specified in the PARM parame¬ 
ter of the EXEC statement 


The option list must begin on a half¬ 
word boundary (one that is not also a 
full-word boundary). The two high- 
order bytes contain a count of the 
number of bytes in the remainder of 
the list. If there are no parameters, 
the count must be zero. The option 
list is free form with each field 


separated by a comma. No blanks 
should appear in the list. 


ddnameaddr 

specifies the address of a variable 
length list containing alternate 
ddnames for the data sets used during 
FORTRAN compiler processing. This 
address is supplied by the invoking 
program. If standard ddnames are 
used, this operand may be omitted. 

The ddname list must begin on a half¬ 
word boundary (one that is not also a 
full-word boundary). The two high- 
order bytes contain a count of the 
number of bytes in the remainder of 
the list. Each name of less than 
eight bytes must be left justified and 
padded with blanks. If an alternate 
ddname is omitted from the list, the 
standard name is assumed. If the name 
is omitted within the list, the 8-byte 
entry must contain binary zeros. 
Names can be omitted only from the end 
of the list. 

The sequence of the 8-byte entries in 
the ddname list is as follows: 

Entry Alternate Name 

1 SYSLIN 

2 00000000 

3 00000000 

4 00000000 

5 SYSIN 

6 SYSPRINT 

7 SYSPUNCH 

VL=1 

specifies that the sign bit of the 
last full-word of the address parame¬ 
ter list is to be set to 1. 


Appendix A: 
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APPENDIX B: EXAMPLES OF JOB PROCESSING 


The following examples show several 
methods to process load modules. 


Example 1: 

Problem Statement: A previously created 

and cataloged data set 

SCIENCE.MATH.MATRICES contains a set of 80 
matrices. Each matrix is an array contain¬ 
ing real variables. The size of the matri¬ 
ces varies from 2x2 to 25x25; the average 
size is 10x10. The matrices are inverted 
by a load module MATINV in the PDS MAT- 
PROGS. Each inverted matrix is written 
(assume FORMAT control) as a single record 
on the data set SCIENCE.MATH.INVMATRS. The 
first variable in each record denotes the 
size of the matrix. 


The I/O flow for the example is shown in 
Figure 59. The job control statements used 
to define this job are shown is Figure 60. 



Figure 59. Input/Output Flow for Example 1 


Explanation: The JOB statement identifies 
the programmer as JOHN SMITH and supplies 
the account number 537. Both control 
statements and control statement error mes¬ 
sages are printed on the SYSOUT data set. 


The JOBLIB DD statement indicates that 
the private library MATPROGS is concatenat¬ 
ed with the system library. 

The EXEC statement indicates that the 
load module MATINV is executed. 

DD statement FT08F001 identifies the 
input data set, SCIENCE.MATH.MATRICES. (In 
the load module, data set reference number 
8 is used to read the input data set.) 
Because this data set has been previously 
created ana cataloged, no information other 
than the data set name and disposition has 
to be supplied. 

DD statement FT10F001 identifies the 
printed output. (In the load module, data 
set reference number 10 is used for printed 
output.) The data set is written on the 
class of devices specified in the SYSOUT 
parameter. 

DD statement FT04F001 defines the output 
data set. (In the load module, data set 
reference number 4 is used to write the 
data set containing the inverted matrices.) 
Because the data set is created and cata¬ 
loged in this job step, a complete data set 
specification is supplied. 



I 



Sample Coding Form 


I -10 


11-20 21-30 31-40 41-50 51- 

I |2|3|4|5|6l7|8l9l0l 1 12131415161718191Ol I 1213[^TsTs171819lo| I l2|3|4|5|6|7|8|9|o| I |2|3|4|5 


60 61- 
6|7181910| I 12131415 


70 , 

61718191011 


71-80 

. 6 1 7 1 8 1910 


I|2|3|4|5|6l7|8|9|0 


2131415 


//INVjERT J , 0B 53,7^JOHNSMI^H^MSGlEVELfl, 


//JOB,LIB D,D D 

■ ■1 1 11 1 1 1! 1 . 1 1 .1 1 


SN,AME-MATPROGS t PI SP=OLD 


//INVERT. EXEC 


i_i_ l 1 1 


l P|GM = ,M^ T ,I,N,V l 




J_I_1 ]_L 




DSNAME^SCIEiKICE . M | A,T,H .,M|A,T RI C i ESi pi ,S,P=0L , p 


/./.FTl ftFgffl , DD 


^YSOUTfA 


_i_l__l_l—I—i—I—i—l_I l_ 


/ 7 f,Tfl 4 .Fflg.il PP, 


PSNA M EpSCI ,E|N,CE,. M i A.TH,. ,1 |N,V,MAT,R,Sa , 


/,/, 


_i_1_i_i_L 1- 


pi ,S P^CN EVy^C AT LG,), ?| UNI,T. = ,D ,AC,L ASS,,,VOLUME, 




1.089,W •>, 


II 


^PACEp, (4,0,8ir(,80,^^TrRLiSEiCO^TIG^,ROUND,) 


)SEP 


FT08F00! 


II 


I—L. I I I I I 


iDCB-C i RECFMrVB^LiRECL = 908^ BLKSJi?E = 27 28 


. i i i-i. 


J-L. 


Figure 60. Job Control Statements for Example 1 
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The DSNAME parameter indicates that the 
data set is named SCIENCE.MATH.INVMATRS. 
The DISP parameter indicates that the data 
set is new and is to be cataloged. The 
SPACE parameter indicates that space is 
reserved for 80 records, 408 characters 
long (80 matrices of average size). When 
space is exhausted, space for 9 more 
records is allocated. The space is con¬ 
tiguous; any unused space is released, and 
allocation begins and ends on cylinder 
boundaries. 

The DCB parameter indicates variable- 
length records, because the size of 
matrices vary. The record length is speci¬ 
fied as 2508, the maximum size of a 
variable-length record. (The maximum size 
of a record in this data set is the maximum 
number of elements (2500) in a matrix 
multipled by the number of bytes (4) allo¬ 
cated for an element, plus 4 for the 
variable that indicates the size of the 
matrix, plus 4 for the control field that 
contains system control information.) The 
buffer length is specified as 2512 (the 4 
bytes are for a control field that contains 
a count of the number of data bytes in a 
record). 

The SEP parameter indicates that the 
data set SCIENCE.MATH.INVMATRS should use a 


different channel from that used for data 
set SCIENCE.MATH.MATRICES. 


Example 2: 

Problem Statement: A previously created 
data set RAWDATA contains raw data from a 
test firing. A load module PROGRD refines 
data by comparing the data set RAWDATA 
against a forecasted result, PROJDATA. The 
output of PROGRD is a data set £REFDATA, 
which contains the refined data. 


The refined data is used to develop 
values from which graphs and reports can be 
generated. The load module ANALYZ contains 
a series of equations and uses a previously 
created and cataloged data set PARAMS which 
contains the parameters for these equa¬ 
tions. ANALYZ creates a data set &VALUES, 
which contains intermediate values. 


These values are used as input to the 
load module REPORT, which prints graphs and 
reports of the data gathered from the test 
firing. Figure 1 in the "Introduction" 
shows the I/O flow for the example. Figure 
61 shows the job control statements used to 
process this job. 


Sample Coding Form 


1- 10 

11-20 

21-30 

31-40 

41-50 

51-60 

61-70 

71-80 

I|2I3|4|5I6|7|8(9I0I 

1 1(2(314(5(6171819101 

1 |2|3|4|5|6|7|8|9|0 

1 |2|3|4|5I6I7I8|9|0 

1 |2|3|4|5|6|7|8|9|0 

1 [2I3I4I5I6I7I8I9I0 

II2I3I4I5I6I7IQI9I0 1 

1 |213!4]5|6|7|8|9I0 


//TE^TFIRE , JOB, ,,J0,HKI,SMI,TH ir MSGLEV EL = l, 


//.J.QfrLI.B, ,D | D, P,S,H AME=,F | IRIN i 6irDI,S i P | =(,0 i LP l rPASS) 


//.SJfiP.l, ,E,X | E,C, ,P l G/V\=P l R l 0 | G l R,D l , 


_Lj_ 


j _i_i__L_ 


/,/ F,T,1,0F,001| DP, fiSNAMErRAyypAJATDISP^QLD, 


/,/,FT,UF,001 DP D^KIAMEr.PRO.J.PATA^DI.SP-AL.D , 


/./.F,T,1 I 2,F,0,01 | ,D,D, P.SNAMEp&REF^ATArDISPnCNEVy.PA 




JA 


EC.L 


/,/ 


/ .. .. 


iVp,L i U i M l E = ( ir R|E i T i A l I l N l rSE i R i -|2 i l i 07), r 


-l 1 I i i i 


/./ 


l D,C,B,= C | D,EN=,2 l rR.E,C,F | M= l F i rB l L l K,S,I l Z | E = 


Wi). 


//, S ,T,E|P,2. EXiEC, PG,M- 






i I _l_l_l_i_ 


//.F|T,1|7F,001 | DP, ,D|5NAMErft,.ST|EP1,. FT 12F001,3,DIftP, 


=,QL,P 


/,/FT,l|8F,001 , DP D l S.M,A.ME | =PARAMSrDI |S, P=0 L,D i 


/,/FT,2,08001 , DP .D l SNAME | =&VAL,UESrDISP = (pEWrPAS 


SbiUNIT 


AP 


CjLS 


/,/ 


i i i i 


, iD,C,B, s ,( | D,E,N, s .2i),R,E,C,F|M, s ,F,?,B|L,K,S,I^ | E, s 




u 


ME 


SiER, 


, 2,1 


, 0 , 


, 8 , 


//SWA ,EX|EC P6M-,REPORT , 


//,F,T,08,F,0,01i DP, ,D|S>J,A,M,Er,X-,.,S,T|E,P2,vF|T,2,0,F0i01,rD,I|S,P, 


: QL|D, , , 


//,FT,1,08001, ,D,D, ,U,NIT-PRINTER 


I I I I I I 




Figure 61. Job Control Statements for Example 2 
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The load modules REFDAT, ANALYZ, and 
REPORT are contained in the private library 
FIRING. 

Explanation: The JOB statement indicates 
the programmer’s name, JOHN SMITH, and that 
control statements and control statement 
error are printed on the console typewrit¬ 
er. 


The JOBLIB DD statement indicates that 
the private library FIRING is concatenated 
with the system library. 


The EXEC statement STEP1 defines the 
first job step in the job and indicates 
that the load module PROGRD is executed. 


The DD statements FT10F001 and FT11F001 
identify the data sets containing raw data 
(RAWDATA) and the forecasted result 
(PROJDATA), respectively. 


DD statement FT12F001 defines a tempora¬ 
ry data set, £REFDATA, created for input to 
the second step. (In the load module, data 
set reference number 12 is used to write 
&REFDATA.) The DISP parameter indicates 
that a data set is new and is passed. The 
data set is written using the device class 
TAPECLS. The VOLUME parameter indicates 
that the volume identified by serial number 
2107 is used for this data set. The DCB 
parameter indicates that the volume is 
written using high density; the records are 
fixed-length blocked; the record length is 
400; and the buffer length is 2000. 


The EXEC statement STEP2 defines the 
second job step in the job and indicates 
that the load module ANALYZ is executed. 


DD statement FT17F001 identifies the 
data set which contains refined data. The 
DSNAME parameter indicates that the data 
set name is copied from DD statement 
FT12F001 in job step STEP1. The DISP 
parameter indicates that the data set is 
deleted after execution of this job step. 
The DD statement FT18F001 identifies the 
previously created and cataloged data set 
PARAMS. 


DD statement FT20F001 defines the tem¬ 
porary data set SVALUES containing the 
intermediate values. The DISP parameter 
indicates that the data set is created in 
this step, and that it is passed to the 
next job step. The data set is written on 
volume 2108 using one of the devices 
assigned to the class TAPECLS. The DCB 


parameter indicates high density and fixed- 
length blocked records. Each record is 204 
characters long. 

The EXEC statement STEP3 defines the 
third job step and indicates that the load 
module REPORT is executed. 


DD statement FT08F001 identifies the 
data set containing intermediate values. 
The DSNAME parameter indicates that the 
data set name is copied from the DD state¬ 
ment FT20F001 in job step STE:P2. 


DD statement FT10F001 indicates that the 
data set reference number 10 is used to 
print the reports and graphs for job step 
three. 


Example 3: 

A data set has been created that con¬ 
tains master records for an index of stars. 
Each star is identified by a unique six¬ 
digit star identification number. Each 
star is assigned a record position in the 
data set by truncating the last two digits 
in the star identification number. Because 
synonyms arise, records are chained. 


The following conventions must be 
observed processing this data set: 

1. The star master record that contains 
the record location counter pointing 
to space reserved for chained records 
is assigned to record location 1. 

2. A zero in the chain variable indicates 
that the end of a chain has been 
reached. 

3. The first variable in each star master 
record is the star identification 
field; the second variable in each 
star master is the chain variable. 

4. Each record contains six other varia¬ 
bles that contain information about 
that star. 


Problem Statement: Figure 62 shows a block 
diagram illustrating the logic for this 
problem. 

A card data set read from the input 
stream is used to update the star master 
data set. Each record (detail record) in 
this data set contains: 

1. The star identification field of the 
star master record that the detail 
record is used to update. 
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Six variables that are to be used to 
update the star master. 

When a star detail record is read, its 
identification field is randomized, and the 
appropriate star master record is read. If 
the correct star master record is found, 
the record is to be updated. If a star 
master is not found, then a star master 
record is to be created for that star. 


The last record in the star detail data 
set contains a star identification number 
999999 which indicates that processing the 
star detail data set is completed. 


Explanation: Figure 62 is similar to the 
diagram shown in Figure 48, except Figure 
62 includes blocks that describe updating 
variables in master records already present 
in the data set. (Figure 48 includes 
blocks describing certain operations that 
must be performed when a direct access data 
set is first written.) Also, Figure 62 is 
adapted to Example 3, while Figure 48 is 
more general. Figure 64 shows the FORTRAN 
coding for this program. 


The star master record that contains the 
record counter is read, placing the record 
location counter in LOCREC. Whenever a 
detail record is read the identification 
variable is checked to determine if the end 
of the detail data set has been reached. 
The star detail records contain the varia¬ 
bles A, B, C, D, E, and F. 


The identification number in the detail 
record is randomized and the result is 
placed in the variable NOREC, which is used 
to read a master record. The master record 
contains the star identification number 
(IDSTRM), a chain record location (ICHAIN), 
and six variables (T, U, V, X, Y, and Z) 
which are to be updated by the variables in 
the star detail records. IDSTRM and IDSTRD 
are compared to see if the correct star 
master is found. If it is not found, then 
the variables containing the chain record 
numbers are followed until the correct star 
master is found or a new star master is 
created. 



Job Control Statements: The program shown 
in Figure 64 is compiled and link edited, 
placing the load module in the PDS STARPGMS 
and assigning the load module the name 
UPDATE. The data set that contains the 
star master records was cataloged and 
assigned the name STARMSTR when it was 
created. Figure 63 shows the job control 
statements needed to execute the module 
UPDATE. 


Figure 62. Block Diagram for Example 3 
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1-10 ' 1 11-20 

21-30 

31-40 

41-50 

31-60 

61-70 

o 

CD 

1 naHOHUML JHHDHHaHHHnnH 

HHQUkJLJMuEjQ 


nHBDB00O]00 

HHBdHBHBBEI 

HHBQBBHBBH 

nRHGHHHnnHl 


Sample Coding Form 


//SJARDAUP, JOB, ,3.2.37'J.ASTRONOMER'/>,M,SGLEVEL-1 
//,JOB|L.Ib' d|p DSN|AME=$ i TARP6|mS')DI|SP=OL|D " 


/,/, EX,E,C, PGjM-UPPATE 


l l-i I l l 1 i 


//FT07F001, DD D,SNAME=STARMSTRtMSP= i OLD 

i l l l.l.l l l.lJ l l l 1.-1.1 —l i i i.i ) l f l i i i l i..i 1...1 t i i 


.1 1 I 




// FT01F001, DD * 


STAR DETAILS 

■ ■ | M M I ■ 


follow; 


7 * 


, , , Stgr Derail ,Data fiet 


END, OF SJ~AR D'ETAIL,S 


1 I 1 I I I I 



Figure 63. Job Control Statements for Example 3 
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Figure 64. FORTRAN Coding for Example 3 
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APPENDIX C: ASSEMBLER LANGUAGE SUBPROGRAMS 


A FORTRAN programmer can use assembler 
language subprograms with his FORTRAN main 
program. This' section describes the link¬ 
age conventions that must be used by the 
assembler language subprogram to communi¬ 
cate with the FORTRAN main program. To 
understand this appendix, the reader must 
be familiar with the Assembler Language 
publication and the Assembler Programmer's 
Guide. 


SUBROUTINE REFERENCES 

The FORTRAN programmer can refer to a 
subprogram in two ways: by a CALL statement 
or a function reference within an arithmet¬ 
ic expression. For example, the statements 

CALL MYSUB(X,Y,Z) 

1=J+K+MYFUNC(L,M,N) 

refer to a subroutine subprogram MYSUB and 
a function subprogram MYFUNC, respectively. 

For subprogram reference, the compiler 
generates: 

1. A contiguous argument list; the 
addresses of the arguments are placed 
in this list to make the arguments 
accessible to the subprogram. 

2. A save area in which the subprogram 
can save information related to the 
calling program. 

3. A calling sequence to pass control to 
the subprogram. 

Argument List 

The argument list contains addresses of 
variables, arrays, and subprogram names 
used as arguments. Each entry in the 


argument list is four bytes and is aligned 
on a full-word boundary. The last three 
bytes of each entry contain the 24-bit 
address of an argument. The first byte of 
each entry contains zeros, unless it is the 
last entry in the argument list. If this 
is the last entry, the sign bit in the 
entry is set to one. 

The address of the argument list is 
placed in general register 1 by the calling 
program. 


Save Area 

The calling program contains a save area 
in which the subprogram places information, 
such as the entry point for this program, 
an address to which the subprogram returns, 
general register contents, and addresses of 
save areas used by programs other than the 
subprogram. The amount of storage reserved 
by the calling program is 18 words. Figure 
65 shows the layout of the save area and 
the contents of each word. The address of 
the save area is placed in general register 
13. 

FORTRAN programs do not save floating¬ 
point registers before a call. The called 
subprogram has to save and restore them. 

Calling Sequence 

A calling sequence is generated to 
transfer control to the subprogram. The 
address of the save area in the calling 
program is placed in general register 13. 
The address of the argument list is placed 
in general register 1, and the entry 
address is placed in general register 15. 
A branch is made to the address in register 
15 and the return address is saved in 
general register 14. Table 13 illustrates 
the use of the linkage registers. 
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AREA-> r - 

(word 1) j This word is a part of the standard linkage convention 

used by the operating system. An assembler language 
subprogram can use the word for any purpose. 


AREA+4- 

(word 2) 


AREA+8- 

(word 3) 

AREA+12- 

(word 4) 


AREA+16- 

(word 5) 

AREA+20- 

(word 6) 

AREA+24- 

(word 7) 


h 


■> F 

I 

-> K 


-> h 

I 

> k 

I 

-> K 


If the program that calls the assembler language 
subprogram is itself a subprogram, this word contains 
the address of the save area of the calling program; 
otherwise, this word is not used. 


H 


The address of the save area of the called subprogram. 


The contents of register 14(the return address). When 
the subprogram returns control, the first byte of this 
location is set to ones. 


The contents of register 15(the entry address) 


The contents of register 0. 


The contents of register 1. 


AREA* 6 8-> 1-- 

(word 18) | The contents of register 12. 

L_ 


Figure 65. Save Area 


Table 13. 


r- T 

Register 

Number 


Linkage Registers 
- T - 


h 


Register Name 


Function 


H 


o 


Result Register 


Used for function subprograms only. The result is returned in 
general or floating-point register 0. However, if the result 
is a complex number, it is returned in floating-point reg¬ 
isters 0 (real part, and 2 (imaginary part). 

Note: For subroutine subprograms, the result(s) is returned in 


a variable(s) passed by the programmer. 


H 


Argument List 
Register 


Address of the argument list passed to the called subprogram. 


2 

13 


Result Register 


See Function of Register 0. 


Save Area 
Register 


Address of the area reserved by the calling program in which 
the contents of certain registers are stored by the called 
program. 




14 


Return Register 


Address of the location in the calling program to which 
control is returned after execution of the called program. 


15 


Entry Point 
Register 


Address of the entry point in the called subprogram. 

Note; Register 15 is also used as a condition code register, a 
RETURN code register, and a STOP code register. The particu¬ 
lar values that can be contained in the register are: 

16 - terminal error detected during execution of a subprogram 
(an IHCxxxI message is generated) 

4*i - a RETURN i statement is executed 
n - a STOP n statement is executed 
0 - a RETURN or a STOP statement is executed 
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CODING THE ASSEMBLER LANGUAGE SUBPROGRAM 

Two types of assembler language subpro¬ 
grams are possible: the first type (lowest 
level) assembler subprogram does not call 
another subprogram; the second type (higher 
level) subprogram does call another subpro¬ 
gram. 

Coding a Lowest Level Assembler Language 
Subprogram 

For the lowest level assembler language 
subprogram, the linkage instructions must 
include: 

1. An assembler instruction that names an 
entry point for the subprogram. 

2. An instruction(s) to save any general 
registers used by the subprogram in 
the save area reserved by the calling 
program. 

3. An instruction(s) to restore the 
"saved” registers before returning 
control to the calling program. 

4. An instruction that sets the first 
byte in the fourth word of the save 
area to ones, indicating that control 
is returned to the calling program. 

5. An instruction that returns control to 
the calling program. 

Figure 66 shows the linkage conventions 
for an assembler language subprogram that 
does not call another subprogram. In addi¬ 
tion to these conventions, the assembler 
program must provide a method to transfer 
arguments from the calling program and 


return the arguments to the calling pro¬ 
gram. 


Higher Level Assembly Language Subprogram 

A higher level assembler subprogram must 
include the same linkage instructions as 
the lowest level subprogram, but because 
the higher level subprogram calls another 
subprogram, it must simulate a FORTRAN 
subprogram reference statement and include: 

1. A save area and additional instruc¬ 
tions to insert entries into its save 
area. 

2. A calling sequence and a parameter 
list for the subprogram that the high¬ 
er level subprogram calls. 

3. An assembler instruction that indi¬ 
cates an external reference to the 
subprogram called by the higher level 
subprogram. 

4. Additional instructions in the return 
routine to retrieve entries in the 
save area. 

Figure 67 shows the linkage conventions 
for an assembler subprogram that calls 
another assembler subprogram. 

In-Line Argument List 

The assembler programmer may establish 
an in-line argument list instead of out-of¬ 
line list. In this case, he may substitute 
the calling sequence and argument list 
shown in Figure 68 for that shown in Figure 
67. 


r- t-T- 

|Name |Oper.|Operand 

i-- + -+- 


Comments 


deckname 

|START 

|0 



j BC 

|15,m+1 + 4(15) 

BRANCH AROUND CONSTANTS IN CALLING SEQUENCE 


| DC 

| X * m' 

m MUST BE AN ODD INTEGER TO INSURE THAT THE PROGRAM 


| DC 

j CLm' name* 

STARTS ON A HALF-WORD BOUNDARY. THE NAME CAN BE PADDED 

* 


1 

WITH BLANKS. 


| STM 

|14,R,12(13) 

THE CONTENTS OF REGISTERS 14, 15, AND 0 THROUGH R ARE 

* 


1 

STORED IN THE SAVE AREA OF THE CALLING PROGRAM. R IS ANY 

* 


I 

NUMBER FROM 2 THROUGH 12. 


| BALR 

1 B, 0 

ESTABLISH BASE REGISTER (2<B<12) 


|USING 

|*,B 



j user 

|written source statements 

i • 

l 


| LM 

1 

• 

|2,R,28(13) 

RESTORE REGISTERS 


j MV I 

| 12(13),X* FF* 

INDICATE CONTROL RETURNED TO CALLING PROGRAM 


j BCR 

115,14 

RETURN TO CALLING PROGRAM 


Figure 66- Linkage Conventions for Lowest Level Subprogram 
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r - T - T - 

|Name |Oper.|Operand 
y -1-+- 


Comments 


j deckname 

|START 

1 o 






j EXTRN 

| naire 2 

NAME OF THE SUBPROGRAM CALLED BY THIS SUBPROGRAM 




j BC 

j15,m+l + 4(15) 






j DC 

| X • m' 






j DC 

j CLm'name^ 





1 * 

1 

|SAVE ROUTINE 






| STM 

|14,R,12(13) 






j BALR 

| B, 0 

ESTABLISH BASE REGISTER 





jUSING 

1 *.B 






j LR 

IQ,13 

LOADS REGISTER 13, WHICH POINTS TO THE SAVE 

AREA 

OF THE 


1 * 

1 


CALLING PROGRAM, INTO ANY GENERAL REGISTER, 

Q, EXCEPT 0 


1 * 

1 


AND 13. 





j LA 

| 13 , AREA 

LOADS THE ADDRESS OF THIS PROGRAM'S SAVE AREA INTO 


1 * 

1 


REGISTER 13. 





| ST 

|13,8(0,Q) 

STORES THE ADDRESS OF THIS PROGRAM'S SAVE AREA INTO THE 


1 * 

1 


CALLING PROGRAM'S SAVE AREA 





| ST 

|Q f 4(0,13) 

STORES THE ADDRESS OF THE PREVIOUS SAVE AREA 

(THE 

SAVE 


1 * 

1 


AREA OF THE CALLING PROGRAM) INTO WORD 2 OF 

THIS 

PRO- 


1 * 

1 


GRAM'S SAVE AREA 





j BC 

j15,prob ± 





| AREA 

|DS 

118F 

RESERVES 18 WORDS FOR THE SAVE AREA 




1 * 

1 

|END OF SAVE ROUTINE 




j prob ± 

| user 

jwritten program statements 

i 

1 




1 * 

1 

1 

i 

|CALLING SEQUENCE 





| LA 

|1,ARGLIST 

LOAD ADDRESS OF ARGUMENT LIST 





|L 

|15,ADCON 






| BALR 

114,15 






j more 

i 

|user written program statements 

i 

i 




1 * 

1 

i 

|RETURN ROUTINE 





1 L 

|13,AREA+4 

LOADS THE ADDRESS OF THE PREVIOUS SAVE AREA 

BACK 

INTO 


1 * 

1 

1 

REGISTER 13 





| LM 

|2,R,28(13) 






|L 

|14,12(13) 

LOADS THE RETURN ADDRESS INTO REGISTER 14. 





j MVI 

|12(13),X'FF' 






| BCR 

115,14 

RETURN TO CALLING PROGRAM 




1 * 

1 

j END OF RETURN 

ROUTINE 




|ADCON 

j DC 

j A(name 2 ) 





1 * 

1 

(ARGUMENT LIST 





|ARGLIST 

j DC 

l 

j AL4(arg t ) 

1 

1 

ADDRESS OF FIRST ARGUMENT 





| DC 

1 

jx'so' 

INDICATE LAST ARGUMENT IN ARGUMENT LIST 





j DC 

j AL3(arg n ) 

ADDRESS OF LAST ARGUMENT 





Figure 67. Higher Level Assembler Subprogram 
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ADCON 

DC 

A(prob ± ) 


LA 

14,RETURN 


L 

15,ADCON 


CNOP 

2,4 


BALR 

1,15 


DC 

AL4(arg ± ) 


DC 

AL4(arg 2 ) 


DC 

X' 80' 


DC 

AL3(arg n ) 

RETURN 

BC 

0,X 1 isn * 


L_J 

Figure 68. In-Line Argument List 

Sharing Data in COMMON 

Both named and blank COMMON in a FORTRAN 
IV program can be referred to by an 
assembly language subprogram. To refer to 
named COMMON, the V-type address constant 

name DC V(name of COMMON) 


The address of a variable in the calling 
program is placed in the argument list. 
The following instructions in an assembler 
language subprogram can be used to move the 
real*8 variable A to location VAR in the 
subprogram. 


L Q,0(1) 

MVC VAR(8),0(Q) 

Where: 

Q is any general register except 0. 

For a subprogram reference, an address 
of a storage location is placed in the 
argument list. The address at this storage 
location is the entry point to the subpro¬ 
gram. The following instructions can be 
used to enter subprogram B from the subpro¬ 
gram to which B is passed as an argument. 

L Q,4(1) 

L 15,0(Q) 

BALR 14,15 

Where: 

Q is any general register except 0. 


is used. 

If a FORTRAN program has a blank COMMON 
area and blank COMMON is also defined (by 
the COM instruction) in an assembly lan¬ 
guage subprogram, only one blank COMMON 
area is generated for the output load 
module. Data in this blank COMMON is 
accessible to both programs. 


RETRIEVING ARGUMENTS FROM THE ARGUMENT LIST 

The argument list contains addresses for 
the arguments passed to a subprogram. The 
order of these addresses is the same as the 
order specified for the arguments in the 
calling statement in the main program. The 
address for the argument list is placed in 
register 1. For example, when the state¬ 
ment 

CALL MYSUB(A,B,C) 

is compiled, the following argument list is 
generated. 

r- t- 

|00000000| address for A 

^- + - 

|00000000| address for B 

h- + - 

|10000000| address for C 

i_-L- 

For purposes of discussion, A is 
real*8 variable, B is a subprogram name 

and C is an array. 


For an array, the address of the first 
variable in the array is placed in the 
argument list. An array [for example, a 
three-dimensional array C (3,2,2)] appears 
in this format in main storage: 

C(l,l,l) C(2,l,l) C(3,1,1) C(1,2,1)- 

r- J 

—C(2,2,l) C(3,2,1) C(1,1,2) C(2,l,2)- 

r- J 

—C(3,l,2) C(l,2,2) C(2,2,2) C(3,2,2) 

Table 14 shows the general subscript 
format for arrays of 1, 2, and 3 dimen¬ 

sions . 

Table 14. Dimension and Subscript Format 

r- 1 

|Array A Subscript Format | 

j.- T ----| 

|A(Dl) |A(Si) | 

j A(D1,D2) j A(SI,S2) j 

|A(D1,D2,D3) j A(SI,S2,S3) j 

h-r-_| 

|Dl, D2, and D3 are integer constants used| 
jin the DIMENSION statement. Si, S2, andj 
|S3 are subscripts used with subscripted! 

|variables. | 

l -j 

-| The address of the first variable in the 

array is placed in the argument list. To 
■| retrieve any other variables in the array, 

the displacement of the variable, that is, 
J the distance of a variable from the first 

variable in the array, must be calculated, 
a The formulas for computing the displacement 

(DISPLC) of a variable for one, two, and 
three dimensional arrays are 
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S,0(Q,R) 
S # ARVAR 


DISPLC=(S1-1)*L 

DISPLC=(Sl-1)*L+(S2-1)*Dl *L 

DISPLC=(Sl-1)*L+(S2-1)*D1*L+(S3-1)*D2*D1*L 
Where: 

L is the length of each variable in 
the array. 

For example, the variable C(2,l,2) in 
the main program is to be moved to a 
location ARVAR in the subprogram. Using 
the formula for displacement of variables 
in a three-dimensional array, the displace¬ 
ment (DISPLC) is calculated to be 28. The 
following instructions can be used to move 
the variable, 

LA Q,8(13) 

LA R,DISPLC 


L 

ST 

Where: 

Q, R, and S are general registers; Q 
and R cannot be general register 0. 


Example: An assembler language subprogram 
is to be named ADDARR, and a real variable, 
an array, and an integer variable are to be 
passed as arguments to the subprogram. The 
statement 

CALL ADDARR (X,Y,J) 

is used to call the subprogram. Figure 69 
shows the linkage used in the assembler 
subprogram. 


r- t-t--- 1 


j Name 

i 

|Oper. 

1 

| Operand 

l 






r 

T 

1 






jADDARR 

j START 

|0 






j B 

|EQU 

|8 







j BC 

|15,12(15) 







j DC 

| X ’ 6 ' 







j DC 

j CL6'ADDARR' 






|ADDARR 

j STM 

|14,12,12(13) 







j BALR 

1 B, 0 







USING 

|*,B 







|L 

| 2 f 8 (1) 

MOVE THIRD ARGUMENT TO 

THE LOCATION 

CALLED 

INDEX 

IN 


j MVC 

|INDEX(4 ) ,0(2) 

THE ASSEMBLER LANGUAGE 

SUBPROGRAM. 





j L 

|3,0 (1) 

MOVE FIRST ARGUMENT TO 

THE LOCATION 

CALLED 

VAR IN 

THE 


MVC 

|VAR(4) ,0(3) 

ASSEMBLER LANGUAGE SUBPROGRAM 





1 L 

| 4,4 (1) 

LOAD THE ADDRESS OF THE ARRAY TO GENERAL REGISTER 

4. 


1 L 

| 4,4 (4 ) 







j user 

1 

■ 

|written statements 

i • 






1 

| LM 

l 

1 

|14,12,28(13) 







j MVI 

112(13),X* FF• 







j BCR 

115,14 







|DS 

j OF 






|INDEX 

|DS 

|1F 






j VAR 

|DS 

| IF 






L 

.L 

JL 







Figure 69. 


Assembler Subprogram Example 
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APPENDIX D: SYSTEM DIAGNOSTICS 


This appendix contains a detailed de¬ 
scription of the diagnostic messages pro¬ 
duced during compilation and load module 
execution. 


COMPILER DIAGNOSTIC MESSAGES 

Two types of compiler diagnostic messa¬ 
ges are generated - error/warning and sta¬ 
tus . 


Compiler Error/Warning Messages 

The following text contains a descrip¬ 
tion of error/warning messages produced by 
the compiler. The message is shown with an 
explanation. 


IEY001I ILLEGAL TYPE 


Explanation: The variable in an 
Assigned GO TO statement is not an 
integer variable; or the variable 
in an assignment statement on the 
left of the equal sign is of 
logical type and the expression on 
the right side does not corre¬ 
spond. (Condition Code - 8) 


IEY005I ILLEGAL LABEL 

Explanation: Illegal usage of a 
statement label; for example, an 
attempt is made to branch to the 
label of a FORMAT statement. 
(Condition Code - 8) 


IEY006I DUPLICATE LABEL 

Explanation: The label appearing 
in the label field of a statement 
has previously been defined for 
another statement. (Condition 
Code - 8) 


IEY007I ID CONFLICT 

Explanation: The name of a varia¬ 
ble or subprogram has been used in 
conflict with the type that was 
defined for the variable or sub¬ 
program in a previous statement. 
Examples: The name listed in a 
CALL statement is the name of a 
variable; a single name appears 
more than once in the dummy list 
of a statement function; a name 
listed in an EXTERNAL statement 
has been defined in another con¬ 
text. (Condition Code - 8) 


IEY002I LABEL 


Explanation: The statement in 
question is unlabeled and follows 
a transfer of control; the state¬ 
ment therefore cannot be executed. 

(Condition Code - 0) 


IEY003I NAME LENGTH 


Explanation: The name of a varia¬ 
ble, COMMON block, NAMELIST or 
subprogram exceeds six characters 
in length; or two variable names 
appear in an expression without a 
separating operation symbol. 
(Condition Code - 4) 


IEY004I COMMA 

Explanation: The comma required 
in the statement has been omitted. 
(Condition Code - 0) 


IEY008I ALLOCATION 

Explanation: The storage alloca¬ 
tion specified by a source module 
statement cannot be performed 
because of an inconsistency 
between the present usage of a 
variable name and some prior usage 
of that name. Examples : A name 
listeu in a COMMON block has been 
listed in another COMMON block; a 
variable listed in an EQUIVALENCE 
statement is followed by more than 
seven subscripts. (Condition Code 
- 8 ) 

IEY009I ORDER 

Explanation: The statements con¬ 
tained in the source module are 
used in an improper sequence. 
Examples: An IMPLICIT statement 
does not appear as tne first or 
second statement of the source 
module; an ENTRY statement appears 
within a DO loop. (Condition Code 
- 8 ) 
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IEY010I 


SIZE 


Explanation: A number used in the 
source module does not conform to 
the legal values for its use. 
Examples: A label used in a state¬ 
ment exceeds the legal size for a 
statement label; the size specifi¬ 
cation in an Explicit Specifi¬ 
cation statement is not accepta¬ 
ble; an integer constant is too 
large. (Condition Code - 8) 

IEY011I UNDIMENSIONED 

Explanation: A variable name is 
used as an array (i.e., subscripts 
follow the name), and the variable 
has not been dimensioned. 
(Condition Code - 8) 

IEY012I SUBSCRIPT 

Explanation: The number of sub¬ 
scripts used in an array reference 
is either too large or too small 
for the array. (Condition Code - 
8 ) 


IEY013I SYNTAX 

Explanation: The statement or 
part of a statement to which this 
message refers does not conform to 
the FORTRAN IV syntax. Examples : 
The statement cannot be identi¬ 
fied; a non-digit appears in the 
label field; fewer than three 
labels follow the expression in an 
Arithmetic IF statement. 
(Condition Code - 8) 


IEY014I CONVERT 

Explanation: The mode of the con¬ 
stant used in a DATA or in an 
Explicit Specification statement 
is different from the mode of the 
variable with which it is asso¬ 
ciated. The constant is then con¬ 
verted to the correct mode. 
(Condition Code - 0) 

IEY015I NO END CARD 

Explanation: The source module 
does not contain an END statement. 
(Condition Code - 0) 


IEY016I ILLEGAL STA. 

Explanation: The context in which 
the statement in question has been 
used is illegal. Examples : The 
statement "S" in a Logical IF 


statement is a Specification 
statement, a DO statement, etc.; 
an ENTRY statement appears in the 
source module and the source 
module is not a subprogram. 
(Condition Code - 8) 


IEY017I ILLEGAL STA. WRN. 

Explanation: The message is pro¬ 
duced as a result of any of the 
following: a RETURN statement 
appears and the source module is 
not a subprogram; a RETURN I 
statement appears in a FUNCTION 
subprogram. (Condition Code - 0) 


IEY018I NUMBER ARG 

Explanation: The reference to a 
library subprogram specifies an 
incorrect number of arguments. 
(Condition Code - 4) 


IEY019I FUNCTION ENTRIES UNDEFINED 

Explanation: If the program oeing 
compiled is a FUNCTION subprogram, 
and there is no scalar with the 
same name as the FUNCTION nor is 
there a definition for each ENTRY, 
the message appears on the SYS- 
PRINT data set. A list of the 
names in error is printed follow¬ 
ing the message. (Condition Code 
- 0 ) 

IEY020I COMMON BLOCK name ERRORS 

Explanation: This message per¬ 
tains to errors that exist in the 
definitions of EQUIVALENCE sets 
which refer to the COMMON area. 
The message is produced when there 
is a contradiction in the alloca¬ 
tion specified, a designation to 
extend the beginning of the COMMON 
area, or if the assignment of 
COMMON storage attempts to allo¬ 
cate a variable to a location 
which does not fall on the 
appropriate boundary; "name" is 
the name of the COMMON block in 
error. (Condition Code - 4) 

IEY021I UNCLOSED DO LOOPS 

Explanation: The message is pro¬ 
duced if DO loops are initiated in 
the source module, but their ter¬ 
minal statements do not exist. A 
list of the labels which appeared 
in the DO statements but were not 
defined follows the printing of 
the message. (Condition Code - 8) 
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IEY022I 


IEY023I 


IEY024I 


IEY025I 


IEY026I 


IEY032I 


UNDEFINED LABELS 


Compiler Status Messages 


Explanation: If any labels are 
used in the source module but are 
not defined, this message is pro¬ 
duced. A list of the undefined 
labels appears on the lines fol¬ 
lowing the message. However, if 
there' are ho undefined labels, the 
word NONE appears on the same line 
as the message. (Condition Code - 
8) 


The following paragraphs describe the 
messages that are produced during the oper¬ 
ation of the compiler which denote the 
progress of the compilation. Most of the 
messages discussed in this section pertain 
to the conditions that result in the termi¬ 
nation of the compilation. 


IEY027I name ERROR-CARD DELETED 


EQUIVALENCE ALLOCATION ERRORS 

Explanation; This message is pro¬ 
duced when there is a conflict 
between two EQUIVALENCE sets, or 
if there is an incompatible bound¬ 
ary alignment in the EQUIVALENCE 
set. The message is followed by a 
list of the variables which could 
not be allocated according to 
source module specifications. 
(Condition Code - 4) 


Explanation: When an error in 
card format is detected during the 
reading of the source module, this 
message is produced. At the tine 
this message is printed, "name” is 
the name of the data set used for 
the source module input. However, 
if the compiler has made ten 
unsuccessful attempts and has de¬ 
termined that ten cards have bad 
format, the message is produced 
followed by the words 

COMPILATION TERMINATED 


EQUIVALENCE DEFINITION ERRORS 

Explanation: This message denotes 
an error in an EQUIVALENCE set 
when an array element is outside 
the array. (Condition Code - 4) 


on the same line. (Condition Code 
- 16) 


IEY028I NO CORE AVAILABLE-COMPILATION TER¬ 
MINATED 


DUMMY DIMENSION ERRORS 

Explanation; If variables speci¬ 
fied as dummy array dimensions are 
not in COMMON and are not global 
dummy variables, the above error 
message is produced. A list of 
the dummy variables which are 
found in error is printed on the 
lines following the message. 
(Condition Code - 4) 


BLOCK DATA PROGRAM ERRORS 

Explanation: This message is pro¬ 
duced if variables in the source 
module have been assigned to a 
program block but have not be^n 
defined previously as COMMON. A 
list of these variables is printed 
on the lines following the mes¬ 
sage. (Condition Code - 4) 


NULL PROGRAM 


Explanation: This message is pro¬ 
duced when the system is unable to 
supply the compiler with an addi¬ 
tional 4K byte block of roll (or 
table) storage. (Condition Code - 
16) 


IEY029I DECK OUTPUT DELETED 

Explanation: If the DECK option 
has been specified, and an error 
occurs during the process of 
punching the designated output, 
this message is produced. No con¬ 
dition code is generated for this 
error. 


IEY030I LINK EDIT OUTPUT DELETED 

Explanation: If the LOAD option 
has been specified, and an error 
occurs during the process of gen¬ 
erating the load module, this mes¬ 
sage is produced. (Condition Coae 
- 16) 


Explanation: This message is pro¬ 
duced when an end of file mark 
precedes any true FORTRAN state¬ 
ments in the source module. 
(Condition code - 0) 


IEY031I ROLL SIZE EXCEEDED 

Explanation: This message is pro¬ 

duced when the WORK or EXIT roll 
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IHC212I 


(table) has exceeded the storage 
capacity tp which it has been 
assigned, or some other roll used 
by the compiler has exceeded 64K 
bytes of storage. (Condition Code 
- 16) 


LOAD MODULE EXECUTION DIAGNOSTIC MESSAGES 

The load module produces three types of 
diagnostic messages: 

• Execution error messages. 

• Program interrupt messages. 

• Operator messages. 

Execution Error Messages 

In the following text, the error codes 
are given with an explanation describing 
the type of error. Preceding the explana¬ 
tion, an abbreviated name is given indicat¬ 
ing the origin of the error. For any load 
module execution error, a condition code of 
16 is generated and the job step is termi¬ 
nated. 

The abbreviated name for the origin of 
the error is: 


IBC - IHCFCOMH-IHCFCVTH routine 
(performs interruption, conversion, and 
error procedures). 

FIOCS - IHCFIOSH routine (performs I/O 
operations for FORTRAN load module 
execution). 


NAMEL - IHCNAMEL routine (performs the 
processing of NAMELIST specifications). 


IBERR - IHCIBERH routine (performs the 
processing of errors detected during 
execution of the load module). 


DIOCS - IHCDIOSE routine (performs 
direct-access I/O operations for FORTRAN 
load module execution). 


LIB - SYSl.FORTLIB• In the explanation 
of the messages, the module name is 
given followed by the entry point 
name(s) enclosed in parentheses. 


IHC211I 

Explanation: IBC — An invalid 
character has been detected in a 
FORMAT statement. 


Explanation: IBC -- An attempt 
has been made to read or write a 
record, under FORMAT control, that 
exceeds the buffer length. 


IHC213I 

Explanation: IBC — The input 
list in an I/O statement without a 
FORMAT specification is larger 
than the logical record. 


IHC214I 

Explanation: IBC — An attempt 
has been made to write more than 
255 FORTRAN records (without a 
FORMAT specification) within one 
FORTRAN logical RECORD. 


IHC215I 

Explanation: IBC — An invalid 
character exists for the decimal 
input corresponding to an I, E, F, 
or D format code. 


IHC216I 

Explanation: LIB — An illegal 
sense light number was detected in 
the argument list in a call to the 
SLITE or SLITET subroutine. 


IHC217I 

Explanation: IBC — An end of 
data set was sensed during a READ 
operation; that is, a program 
attempted to read beyond the data. 


IHC218I 

Explanation: IBC -- A permanent 
input/output error has been 
encountered, or an attempt has 
been made to read or write with 
magnetic tape a record that is 
less than 18 bytes long. 


IHC219I 

Explanation: FIOCS — A data set 
is referred to in the load module, 
but no DD statement is supplied 
for it or a DD statement has an 
erroneous ddname. 
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IHC220I 


IHC232I 


Explanation: FIOCS — A data set 
reference number exceeds the limit 
specified for data set reference 
numbers when this operating system 
was generated. 


IHC221I 

Explanation: NAMEL — An input 
variable name exceeds eight char¬ 
acters . 


IHC222I 

Explanation: NAMEL — An input 
variable name is not in the NAME- 
LIST dictionary, or an array is 
specified with an insufficient 
amount of data. 


IHC223I 

Explanation: NAMEL — An input 
variable name or a subscript has 
no delimiter. 


IHC224I 

Explanation: A subscript is 
encountered after an undimensioned 
input name. 

IHC225I 

Explanation: IBC -- An illegal 
character is encountered on input 
for the Z format code. 


IHC230I SOURCE ERROR AT ISN xxxx - EXECU¬ 
TION FAILED AT SUBROUTINE-name 

Explanation: IBERR — During load 
module execution, a source state¬ 
ment error is encountered. The 
internal statement number for the 
source statement is xxxx, the rou¬ 
tine that contains the statement 
is specified by "name". 


IHC231I 

Explanation: DIOCS — Direct 
access input/output statements are 
used for a sequential data set, or 
input/output statements for a 
sequential data set are used for a 
direct access data set. 


Explanation: DIOCS — Relative 
position of a record is not a 
positive integer, or the relative 
position exceeds the number of 
records in the data set. 


IHC233I 

Explanation: DIOCS -- The record 
length specified in the DEFINE 
FILE statement exceeus the physi¬ 
cal limitation of the volume 
assigned to the data set in the DD 
statement. 


IBC234I 

Explanation: DIOCS — The data 
set assigned to print execution 
error messages cannot be a direct 
access data set. 


IHC235I 

Explanation: DIOCS -- A data set 
reference number assigned to a 
direct access data set is used for 
a sequential data set. 


IHC236I 

Explanation: IBC — A READ is 
executed for a data set that has 
not been created. 


IHC241I 

Explanation: LIB — For an 

exponentiation operation (I**J) in 
the subprogram IHCFTXPI (F1XPIU) 
where I and J represent integer 
variables or integer constants, I 
is equal to zero and J is less 
than or equal to zero. 

IHC242I 

Explanation: LIB — For an 

exponentiation operation (R**J) xn 
the subprogram IHCFRXPI(FRXPI#), 
where R represents a real*4 varia¬ 
ble or real*4 constant, and J 
represents an integer variable or 
integer constant, R is equal to 
zero and J is less than or equal to 
zero. 

IEC243I 

Explanation: LIB -- For an 

exponentiation operation (D**J) in 
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the subprogram IHCFDXPI (FDXPI#), 
where D represents a real*8 varia¬ 
ble or real*8 constant and J rep¬ 
resents an integer variable or 
integer constant, D is equal to 
zero and J is less than or equal 
to zero. 


IHC244I 


Explanation; LIB — For an 
exponentiation operation (R**S) in 
the subprogram IHCFRXPR(FRXPR#), 
where R and S represent real*4 
variables or real*4 constants, R 
is equal to zero and S is less 
than or equal to zero. 


IHC245I 

Explanation; LIB — For an 
exponentiation operation (D**P) in 
the subprogram IHCFDXPD(FDXPD#), 
where D and P represent real*8 
variables or real*8 constants, D 
is equal to zero and P is less 
than or equal to zero. 

IHC246I 

Explanation; LIB — For an 
exponentiation operation (Z**J) in 
the subprogram IHCFCXPI(FCXPI#), 
where Z represents a complex*8 
variable or complex*8 constant and 
J represents an Integer variable 
or integer constant, Z is equal to 
zero and J is less than or equal 
to zero. 

IHC247I 

Explanation; LIB — For an 
exponentiation operation (Z**J) in 
the subprogram IHCFCDXI(FCDXI#), 
where Z represents a complex*16 
variable or complex*16 constant 
and J represents an integer varia¬ 
ble or integer constant, Z is 
equal to zero and J is less than 
or equal to zero. 


IHC251I 

Explanation: LIB — In the sub¬ 
program IHCSSQRT(SQRT), the argu¬ 
ment is less than 0. 


IHC252I 

Explanation; LIB — In the sub¬ 
program IHCSEXP(EXP), the argument 
is greater than 174.673. 


IHC253I 


Explanation; LIB — In the sub¬ 
program IHCSLOG(ALOG and ALOGlO), 
the argument is less than or equal 
to zero. Because this subprogram 
is called by an exponential sub¬ 
program, this message also indi¬ 
cates that an attempt has been 
made to raise a negative base to a 
real power. 


IHC254I 


Explanation; LIB -- In the sub¬ 
program IHCSSCN(SIN and COS), the 
absolute value of an argument is 
greater than or equal to 2 ;L8 *‘ n ' 
(2 18 »V=.82354966406249996D+06). 


IHC255I 

Explanation; LIB — In the sub¬ 
program IHCSATN2, when entry name 
ATAN2 is used, both arguments are 
equal to zero. 


IHC256I 

Explanation; LIB — In the sub¬ 
program IHCSSCNH(SINH or COSH), 
the argument is greater than or 
equal to 174.673. 


IHC257I 

Explanation; LIB — In the sub¬ 
program IHCSASCN (ARCSIN or 
ARCOS), the absolute value of the 
argument is greater than 1. 


IHC258I 

Explanation; LIB — In the sub¬ 
program IHCSTNCT (TAN or COTAN), 
the absolute value of the argument 
is greater than or equal to 2 ±8 *' nr 
(2i8*ir =. 82354966406249996D + 06) . 


IHC259I 

Explanation; LIB — In the sub¬ 
program IHCSTNCT (TAN or COTAN), 
the argument value is too close to 
one of the singularities 
( »• • • for the tangent 
or -+-7T,H-2 7r i * • • for the cotangent). 
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IHC261I 


Explanation: LIB — In the sub¬ 
program IHCLSQRT(DSQRT), the argu¬ 
ment is less than 0. 


IHC262I 

Explanation: LIB — In the sub¬ 
program IHCLEXP(DEXP), the argu¬ 
ment is greater than 174.673. 


IHC263I 

Explanation: LIB — In the sub¬ 
program IHCLLOG(DLOG and DLOGIO), 
the argument is less than or equal 
to zero. Because the subprogram 
is called by an exponential sub¬ 
program, this message also indi¬ 
cates that an attempt has been 
made to raise a negative base to a 
real power. 


IHC264I 

Explanation: LIB — In the sub¬ 
program IHCLSCN(DSIN and DCOS), 
the absolute value of the argument 
is greater than or equal to 2 5 °*' Tr 
(2 5 o. ^ = . 3537H88737802239D+16) . 


IHC265I 

Explanation: LIB — In subprogram 
IHCLATN2, when entry name DATAN2 
is used, both arguments are equal 
to zero. 


IHC266I 

Explanation: LIB — In the sub¬ 
program IHCLSCNH (DSINH or DCOSH), 
the absolute value of the argument 
is greater than or equal to 
174.673. 


IHC267I 

Explanation: LIB — In the sub¬ 
program IHCLASCN (DARSIN or 
DARCOS), the absolute value of the 
argument is greater than 1. 


IHC268I 

Explanation: LIB — In the sub¬ 
program IHCLTNCNT (DTAN or 
DCOTAN), the absolute value of the 


argument is greater than or equal 
to 2 5 °*tt 

(250.^ = .35371188737802239D+16). 


IHC269I 


Explanation: LIB -- In the sub¬ 

program IHCLTNCT (DTAN or DCOTAN), 
the argument value is too close to 
one of the singularities 

jr_ 3tt for the tangent; 
\ 2 2 ’“‘for the cotangent). 

± 7T , jfc 2 7T, . . . 

IHC271I 


Explanation: LIB — In the sub¬ 
program IHCCSEXP (CEXP), the value 
of the real part of the argument 
is greater than 174.673. 


IHC272I 

Explanation: LIB — In the sub¬ 

program IHCCSEXP (CEXP), the abso¬ 
lute value of the imaginary part 
of the argument is greater than or 
equal to 2 18 •n 

(2 18 •■*■=. 823549 66 4062 49996D+06) . 


IHC273I 

Explanation: LIB — In the sub¬ 
program IHCCSLOG (CLOG), the real 
and imaginary parts of the argu¬ 
ment are equal to zero. 


IHC274I 

Explanation: LIB — In the sub¬ 

program IHCCSSCN (CSIN or CCOS), 
the absolute value of the real 
part of the argument is greater 
than or equal to2 18 » T 

(2 i e•'» r =. 8 235 4966 40 62 49996D+06) . 


IHC275I 

Explanation: LIB — In the sub¬ 
program IHCCSSCN (CSIN or CCOS), 
the absolute value of the imag¬ 
inary part of the argument is 
greater than 174.673. 


IHC281I 

Explanation: LIB — In the sub¬ 

program IHCCLEXP (CDEXP), the 
value of the real part of the 
argument is greater than 174.673. 
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IHC282I 


Program Interrupt Messages 


IHC283I 


IHC284I 


IHC285I 


IHC290I 


IHC291I 


IHC300I 


IHC301I 


Explanation: LIB -- In the sub¬ 

program IHCCLEXP (CDEXP), the 
absolute value of the imaginary 
part of the argument is greater 
than or equal to 2 5 °»-rr 
(250 .tt= . 35371188737802239D + 16) . 


Explanation: LIB — In the sub¬ 
program IHCCLLOG (CDLOG), the real 
and imaginary parts of the argu¬ 
ment are equal to zero. 


Explanation: LIB — In the sub¬ 

program IHCCLSCN (CDSIN or CDCOS), 
the absolute value of the real 
part of the argument is greater 
than or equal to 2 5 °»tr 
(250.^=.35371188737802239D+16). 


Explanation: LIB — In the sub¬ 
program IHCCLSCN (CDSIN or CDCOS), 
the absolute value of the imag¬ 
inary part of the argument is 
greater than 174.673. 


Explanation: LIB — In the sub¬ 
program IHCSGAMA (GAMMA), the 
value of the argument is outside 
the valid range (2- 252 <x<57.5744). 


Explanation; LIB — In the sub¬ 
program IHCSGAMA (ALGAMA), the 
value of the argument is outside 
the valid range (0<x<4. 2937xl0 73 ) . 


Explanation: LIB — In the sub¬ 
program IHCLGAMA (DGAMMA), the 
value of the argument is outside 
the valid range (2" 252 <x<57.5744). 


Explanation: LIB — In the sub¬ 
program IHCLGAMA (DLGAMA), the 
value of the argument is outside 
the valid range (0<x<4.2937xl0 73 ). 


The following text describes program 
interrupt messages. The format of these 
messages is described in "System Output." 

Fixed-Point-Divide Exception: The fixed- 
point-divide exception, assigned code 
number 9, is recognized when division of a 
fixed-point number by zero is attempted. 
For example, a divide exception would occur 
during execution of the following state¬ 
ments 

K=I/J 
Where: 


J=0 and 


1=7 


Exponent-Overflow Exception: The exponent- 
overflow exception, assigned code number C, 
is recognized when the result of a 
floating-point addition, subtraction, 
multiplication, or division is greater than 
or equal to 16 63 (approximately 7.2xl0 75 ). 
For example, an exponent-overflow would 
occur during execution of the statement: 

A=1.OE+75+7.2E+75 

Exponent-Under f low _ Exception: The 

exponent-underflow exception, assigned code 
number D, is recognized when the result of 
a floating-point addition, subtraction, 
multiplication, or division is less than 
16 65 (approximately 5.4x10 79 ). For exam¬ 
ple an exponent-underflow exception would 
occur during execution of the statement: 

A=-l.OE-79-5.4E-79 

Floating-Point-Divide _ Exception: The 

floating-point- divide exception, assigned 
code number F, is recognized when division 
of a floating-point number by zero is 
attempted. For example, a floating-point 
divide exception would occur during execu¬ 
tion of the following statement: 

C=A/B 
Where: 


B=0.0 and 


A=l. 0 


Operator Messages 

Operator messages for STOP and PAUSE are 
generated during load module execution. 

The message for a PAUSE can be one of 
the forms: 
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yy IHC001A 


Where: 


YY 


PAUSE n 

PAUSE ' message * 
PAUSE 0 


is the identification num¬ 
ber 

is the unsigned 1-5 digit 
integer constant specified 
in a PAUSE source statement 


REPLY yy,'z' 


Where: 

yy is the identification number and z 
is any letter or number. To resume 
program; execution the operator must 
press the alternate coding key and a 
numeric 5. 

The message for a STOP statement can be 
one of the forms: 


message is the literal constant 

specified in a PAUSE source 
statement 

0 is printed out when a PAUSE 

statement is executed. 

Explanation: The programmer should give 
instructions that indicate the action to be 
taken by the operator when the PAUSE is 
encountered. 

User Response: To resume execution, the 

operator presses the REQUEST key. When the 
PROCEED light comes on, the operator types 


IHC002I j STOP n ' 
jSTOP 0 


Where: 

n^ is the unsigned 1-5 

digit integer constant 
specified in a STOP 
source statement 

0 is printed when a STOP 

statement is executed 


User Response: None 
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APPENDIX E 


EXTENDED ASA CARRIAGE CONTROL CHARACTERS 



* blank Space 1 one line before printing 

* 0 Space two lines before printing 

Space three lines before printing 

* + Suppress space before printing 

* 1 Skip to first line of a new page 

2 Skip to channel 2 

3 Skip to channel 3 

4 Skip to channel 4 

5 Skip to channel 5 

6 Skip to channel 6 

7 Skip to channel 7 

8 Skip to channel 8 

9 Skip to channel 9 

A Skip to channel 10 

B Skip to channel 11 

C Skip to channel 12 

V Select punch pocket 1 

W Select punch pocket 2 


* These carriage control characters are 
identical to the FORTRAN carriage control 
characters specified in the FORTRAN IV 
Language publication- 
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APPENDIX F: DEBUG FACILITY 


The FORTRAN Debug Facility statements 
(DEBUG, AT, DISPLAY, TRACE ON and TRACE 
OFF) are described in the FORTRAN IV Lan¬ 
guage publication. This section describes 
the output produced when these statements 
are used in a FORTRAN source module. 


DEBUG STATEMENT 

The options UNIT, SUBCHK, TRACE, INIT, 
and SUBTRACE may be specified in the DEBUG 
statement. The UNIT option indicates the 
unit on which the DEBUG output is to be 
written; if this option is omitted, DEBUG 
output is written on SYSOUT. 


TRACE 

TRACE output is written only when TRACE 
is on as a result of the TRACE ON state¬ 
ment. For each labeled statement that is 
executed, the line 

TRACE statement-label 

is written. 


SUBTRACE 

SUBTRACE is used to trace program flow 
from one routine to another. For each 
subprogram called, the line 

SUBTRACE subprogram-name 

is written on entry to the subprogram, and 
the line 

SUBTRACE *RETURN* 

is written on exit from the subprogram. 


INIT 

The output produced as a result of the 
INIT option is written regardless of any 
TRACE ON or TRACE OFF statements in the 
source module. When the value of an unsub- 
scripted variable listed in the INIT option 
changes, the line 

variable-name = value 

is written, with the value given in the 
proper format for the variable type. When 
the value of an element of an array listed 
in the INIT option changes, the line 


array-name(element-number) = value 

is written, with the format of the value 
determined by the type of the array ele¬ 
ment. The single element number subscript 
is used regardless of the number of dimen¬ 
sions on the array. 


SUBCHK 

SUBCHK output is not affected by TRACE 
ON and TRACE OFF statements in the source 
module. When a reference to an array 
listed in the SUBCHK option includes sub¬ 
scripts such that the reference is outside 
the array, the line 

SUBCHK array-name(element-number) 

is printed. The statement including the 
out-of-bounds reference is operated 
nonetheless. 


DISPLAY STATEMENT 

DISPLAY statement output is iaentical to 
NAMELIST WRITE output. The first line 
written is the name of the NAMELIST created 
by the compiler for the DISPLAY statement, 
preceded by the ampersand character: 

£DBGnn# 

where: 

nn is the two-digit decimal value 
assigned to the DISPLAY statement; 
this value begins at 01 for the first 
DISPLAY statement in the source module 
and increases by one for each subse¬ 
quent DISPLAY statement. 

The NAMELIST name is followed by the 
DISPLAY list, in NAMELIST format. The 
output is terminated with the line 

SEND 


SPECIAL CONSIDERATIONS 

Any DEBUG output which is produced dur¬ 
ing an input/output operation is saved in 
storage until the input or output operation 
is complete, when it is written out. Sav¬ 
ing this information may require a request 
for additional storage space from the sys¬ 
tem. If the request cannot £>e satisfied, 
some of the DEBUG output may be lost. If 
this situation occurs, the message 
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SOME DEBUG OUTPUT MISSING 


erence, and the FUNCTION contains a DISPLAY 
statement, the DISPLAY cannot be performed, 
is written after the output which was In this case the message 

saved. 

DISPLAY DURING I/O SKIPPED 

If a subscript appearing in an 

input/output list includes a function ref- is written in the DEBUG output. 
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_Clarification on page(s) 

_Addition on page(s) 

_Deletion on page(s) 

_Error on page(s) 


Explanation: 
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International Business Machines Corporation 
Data Processing Division 
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IBM World Trade Corporation 

B21 United Nations Plaza, New York, New York 10017 
[International] 
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